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Abstract 


This  thesis  introduces  theory  generation ,  a  new  general-purpose  technique  for 
performing  automated  verification.  Theory  generation  draws  inspiration  from,  and 
complements,  both  automated  theorem  proving  and  symbolic  model  checking,  the 
two  approaches  that  currently  dominate  mechanical  reasoning.  At  the  core  of  this 
approach  is  the  notion  of  producing  a  finite  representation  of  a  theory — all  the 
facts  derivable  from  a  set  of  assumptions.  An  algorithm  is  presented  for  producing 
compact  theory  representations  for  an  expressive  class  of  simple  logics. 

Security-sensitive  protocols  are  widely  used  today,  and  the  growing  popularity  of 
electronic  commerce  is  leading  to  increasing  reliance  on  them.  Though  simple  in 
structure,  these  protocols  are  notoriously  difficult  to  design  properly.  Since  spec¬ 
ifications  of  these  protocols  typically  involve  a  small  number  of  principals,  keys, 
nonces,  and  messages,  and  since  many  properties  of  interest  can  be  expressed  in 
“little  logics”  such  as  the  Burrows-Abadi-Needham  (BAN)  logic  of  authentica¬ 
tion,  this  domain  is  amenable  to  theory  generation. 

Theory  generation  enables  fast,  automated  analysis  of  these  security  protocols. 
Given  the  theory  representation  generated  from  a  protocol  specification,  one  can 
quickly  test  for  specific  desired  properties,  as  well  as  directly  manipulate  the  rep¬ 
resentation  to  perform  other  kinds  of  analysis,  such  as  protocol  comparison.  This 
thesis  describes  applications  of  theory  generation  to  more  than  a  dozen  security 
protocols  using  three  existing  logics  of  belief;  these  examples  confirm,  or  in  some 
cases  expose  flaws  in  earlier  analyses. 

This  thesis  introduces  anew  logic,  RV,  for  security  protocol  analysis.  While  draw¬ 
ing  on  the  BAN  heritage,  RV  addresses  a  common  criticism  of  BAN-like  logics: 
that  the  idealization  step  can  mask  vulnerabilities  present  in  the  concrete  protocol. 
By  formalizing  message  interpretation,  RV  allows  the  verification  of  honesty  and 
secrecy  properties,  in  addition  to  the  traditional  belief  properties.  The  final  contri¬ 
bution  of  this  thesis,  the  Revere  protocol  analysis  tool,  has  a  theory  generation 
core  with  plug-in  modules  for  RV  and  other  logics.  Its  performance  is  suitable  for 
interactive  use;  verification  times  are  under  a  minute  for  all  examples. 
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Chapter  1 
Introduction 


1.1  Motivation 

Security-sensitive  protocols  are  widely  used  today,  and  we  will  rely  on  them  even 
more  heavily  as  electronic  commerce  continues  to  expand.  This  class  of  proto¬ 
cols  includes  well-known  authentication  protocols  such  as  Kerberos  [MNSS87] 
and  Needham-Schroeder  [NS78],  newer  protocols  for  electronic  commerce  such 
as  NetBill  [ST95]  and  Secure  Electronic  Transactions  (SET)  [VM96],  and 
“security-enhanced”  versions  of  existing  network  protocols,  such  as  Netscape’s 
Secure  Sockets  Layer  (SSL)  [FKK96],  Secure  HTTP  [RS96],  and  Secure  Shell 
(SSH)  [Gro99]. 

These  protocols  are  notoriously  difficult  to  design  properly.  Researchers  have 
uncovered  critical  but  subtle  flaws  in  protocols  that  had  been  scrutinized  for  years 
or  even  decades.  Protocols  that  were  secure  in  the  environments  for  which  they 
were  designed  have  been  used  in  new  environments  where  their  assumptions  fail 
to  hold,  with  dire  consequences.  These  assumptions  are  often  implicit  and  easily 
overlooked.  Furthermore,  security  protocols  by  their  nature  demand  a  higher  level 
of  assurance  than  many  systems  and  programs,  since  the  use  of  these  protocols 
implies  that  the  user  perceives  a  threat  from  malicious  parties.  The  weakest-link 
argument  requires  that  every  component  of  a  system  be  secure;  since  almost  every 
modem  distributed  system  makes  use  of  some  of  these  protocols,  their  security  is 
crucial. 

Given  these  considerations,  we  must  apply  careful  reasoning  to  gain  confi¬ 
dence  in  security  protocols.  In  current  practice,  these  protocols  are  analyzed 
sometimes  using  formal  methods  based  on  security-related  logics  such  as  the  Bur- 
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rows,  Abadi,  and  Needham  (BAN)  logic  of  authentication,  and  sometimes  using 
informal  arguments  and  public  review.  While  informal  approaches  play  an  impor¬ 
tant  role,  formal  methods  offer  the  best  hope  for  producing  convincing  evidence 
that  a  protocol  meets  its  requirements.  It  is  for  critical  system  properties  like  se¬ 
curity  that  the  cost  of  applying  formal  methods  can  most  easily  be  justified.  The 
formal  protocol  analyses,  when  they  exist,  normally  take  the  form  of  pencil-and- 
paper  specifications  and  proofs,  sometimes  checked  by  mechanized  verification 
systems  such  as  PVS  [ORSvH95].  The  process  of  encoding  protocols  and  secu¬ 
rity  properties  in  a  general-purpose  verification  system  is  often  cumbersome  and 
error-prone,  and  it  sometimes  requires  that  the  protocol  be  expressed  in  an  un¬ 
natural  way.  As  a  result,  the  cost  of  applying  formal  reasoning  may  be  seen  as 
prohibitive  and  the  benefits  uncertain;  thus,  protocols  are  often  used  with  only 
informal  or  possibly-flawed  formal  arguments  for  their  soundness.  If  we  can  de¬ 
velop  formal  methods  that  demand  less  from  the  user  while  still  providing  strong 
assurances,  the  result  should  be  more  dependable  protocols  and  systems. 


1.2  Overview  of  Approach  and  Thesis  Claim 

This  dissertation  introduces  a  new  technique,  theory  generation,  which  can  be 
used  to  analyze  these  protocols  and  facilitate  their  development.  This  approach 
provides  fully  automated  verification  of  the  properties  of  interest,  and  feedback 
on  the  effects  of  refinements  and  modifications  to  protocols. 

At  the  core  of  this  approach  is  the  notion  of  producing  a  finite  representation 
of  all  the  facts  derivable  from  a  protocol  specification.  The  common  protocols 
and  logics  in  this  domain  have  some  special  properties  that  make  this  approach 
appealing.  First,  the  protocols  can  usually  be  expressed  in  terms  of  a  small,  finite 
number  of  participants,  keys,  messages,  nonces,  and  so  forth.  Second,  the  log¬ 
ics  with  which  we  reason  about  them  often  comprise  a  finite  number  of  rules  of 
inference  that  cause  “growth”  in  a  controlled  manner.  The  BAN  logic  of  authenti¬ 
cation,  along  with  some  other  logics  of  belief  and  knowledge,  meets  this  criterion. 
Together,  these  features  of  the  domain  make  it  practical  to  produce  such  a  finite 
representation  quickly  and  automatically. 

The  finite  representation  takes  the  form  of  a  set  of  formulas  T,  which  is  essen¬ 
tially  the  transitive  closure  of  the  formulas  constituting  the  protocol  specification, 
over  the  rules  of  inference  in  a  logic.  This  set  is  called  the  theory,  or  consequence 
closure.  Given  such  a  representation,  verifying  a  specific  property  of  interest,  0, 
requires  a  simple  membership  test:  0  £  T.  In  practice,  the  representation  is  not 
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the  entire  transitive  closure,  and  the  test  is  slightly  more  involved  than  simple 
membership,  but  it  is  similar  in  spirit.  Beyond  this  traditional  property-testing 
form  of  verification,  we  can  make  further  uses  of  the  set  T,  for  instance  in  com¬ 
paring  different  versions  of  a  protocol.  We  can  capture  some  of  the  significant 
differences  between  protocols  P  and  Q  by  examining  the  formulas  that  lie  in  the 
set  difference  Tp  \  Tq  and  those  that  lie  in  Tq  \  Tp. 

Using  this  new  approach,  we  can  provide  protocol  designers  with  a  powerful 
and  automatic  tool  for  analyzing  protocols  while  allowing  them  to  express  the 
protocols  in  a  natural  way.  In  addition,  the  tool  can  be  instantiated  with  a  sim¬ 
ple  representation  of  a  logic,  enabling  the  development  of  logics  tailored  to  the 
verification  task  at  hand  without  sacrificing  push-button  operation. 

Beyond  the  domain  of  cryptographic  protocols,  theory  generation  could  be 
applied  to  reasoning  with  any  logic  that  exhibits  the  sort  of  controlled  growth 
mentioned  above  (and  explained  formally  in  Chapter  2).  For  instance,  researchers 
in  artificial  intelligence  often  use  such  logics  to  represent  planning  tasks,  as  in  the 
Prodigy  system  [VCP+95]. 

The  new  approach  makes  it  easy  to  generate  automatically  a  checker  special¬ 
ized  to  a  given  logic.  Just  as  Jon  Bentley  has  argued  the  need  for  “little  lan¬ 
guages”  [Ben86],  this  generator  provides  a  way  to  construct  “little  checkers”  for 
“little  logics.”  The  checkers  are  lightweight  and  quick,  just  as  the  logics  are  lit¬ 
tle  in  the  sense  of  having  limited  connectives  and  restricted  rules,  but  the  results 
can  be  illuminating.  As  part  of  this  thesis  research,  we  implement  a  system  that 
generates  these  little  checkers,  and  we  apply  four  such  checkers  to  a  variety  of 
protocols. 

The  thesis  of  this  work  is  that  theory  generation  offers  an  effective  form  of 
automated  reasoning,  and  furthermore  that  theory  generation  can  be  applied  in 
the  domain  of  authentication  and  electronic  commerce  protocols  to  analyze  a  wide 
range  of  critical  security  properties. 

1.3  Contributions 

In  demonstrating  this  thesis,  we  make  several  significant  contributions  to  the  fields 
of  formal  methods  and  computer  security. 

First,  theory  generation  is  a  new  approach  for  formal  verification.  The  method 
of  producing  and  directly  manipulating  finite  theory  representations  enables  new 
kinds  of  analysis,  such  as  the  difference  approach  alluded  to  above  for  comparing 
two  specifications.  The  TGf  algorithm  for  theory  generation  provides  a  simple 
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means  of  producing  useful  but  compact  theory  representations  for  an  expressive 
class  of  logics.  As  well  as  the  algorithm  itself,  we  provide  proofs  of  its  correctness 
and  termination,  a  practical  implementation,  and  suggestions  for  further  enhance¬ 
ments. 

Second,  the  application  of  theory  generation  to  the  analysis  of  security  proto¬ 
cols  is  a  new  development.  The  utility  of  this  approach  is  demonstrated  through 
many  examples,  in  which  theory  generation  is  applied  both  to  existing  belief  log¬ 
ics  and  to  a  new  logic,  RV,  for  verifying  protocol  properties.  Future  protocol 
analysis  tools  could  benefit  from  this  technique. 

The  RV  logic  itself  is  a  contribution  in  reasoning  about  security  protocols. 
This  logic  provides  a  formal,  explicit  representation  of  message  interpretations, 
allowing  us  to  bridge  the  “idealization  gap”  that  has  been  a  weakness  of  BAN  and 
related  logics.  In  addition  to  the  traditional  belief  properties  of  the  sort  BAN  deals 
with,  RV  can  express  honesty,  secrecy,  and  feasibility  properties. 

Finally,  the  Revere  protocol  analysis  tool  offers  protocol  designers  an  en¬ 
vironment  in  which  they  can  quickly  check  properties  of  new  protocols  under 
development,  and  it  can  serve  as  a  model  for  future  implementations  of  theory 
generation  and  a  base  for  development  of  more  sophisticated  protocol  analyzers. 


1.4  Related  Work 

There  is  a  rich  history  of  research  on  computer-assisted  formal  verification  and 
on  reasoning  about  security.  This  section  contains  a  brief  survey  of  the  work 
most  relevant  to  the  thesis,  focusing  on  the  important  differences  between  existing 
approaches  and  theory  generation  as  applied  to  security  protocols. 


1.4.1  Theorem  Proving 

General-purpose  automated  theorem  proving  is  the  more  traditional  approach  to 
verifying  security  properties.  Early  work  on  automated  reasoning  about  security 
made  use  of  the  Affirm  [GMT+80],  HDM  [LRS79],  Boyer-Moore  [BM79],  and 
Ina  Jo  [LSSE80]  theorem-proving  methodologies.  This  line  of  work  was  largely 
based  on  the  Bell-LaPadula  security  model  [BL76].  In  proving  the  theorems  that 
expressed  security  properties  of  a  system  or  protocol,  an  expert  user  would  care¬ 
fully  guide  the  prover,  producing  lemmas  and  narrowly  directing  the  proof  search 
to  yield  results. 
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More  recent  theorem-proving  efforts  have  used  the  HOL  [GM93],  PVS 
[ORSvH95],  and  Isabelle  [Pau94]  verification  systems  to  express  and  reason  about 
security  properties.  These  sophisticated  verification  systems  support  specifica¬ 
tions  in  higher-order  logic  and  allow  the  user  to  create  custom  proof  strategies 
and  tactics  with  which  the  systems  can  do  more  effective  automated  proof  search. 
Though  simple  lemmas  can  be  proved  completely  automatically,  human  guidance 
is  still  necessary  for  most  interesting  proofs. 

We  have  done  limited  experiments  in  applying  PVS  to  the  BAN  logic  as  an 
alternative  to  theory  generation.  The  encoding  of  the  logic  is  quite  natural,  but  the 
proofs  are  tedious  because  PVS  is  often  unable  to  find  the  right  quantified- variable 
instantiations  to  apply  the  BAN  logic’s  rules  of  inference. 

Paulson  uses  the  Isabelle  theorem  prover  to  demonstrate  a  range  of  security 
properties  in  an  “inductive  approach”  [Pau96,  BP97].  In  this  work,  he  models  a 
protocol  as  a  set  of  event  traces,  defined  inductively  by  the  protocol  specification. 
He  defines  rules  for  deriving  several  standard  message  sets  from  a  trace,  such  as 
the  set  of  messages  (and  message  fragments)  that  can  be  derived  from  a  trace  H 
using  only  the  keys  contained  in  H.  Given  these  definitions,  he  proposes  various 
classes  of  properties  that  can  be  verified:  possibility  properties,  forwarding  lem¬ 
mas,  regularity  lemmas,  authenticity  theorems,  and  secrecy  theorems.  Paulson’s 
approach  has  the  advantage  of  being  based  on  a  small  set  of  simple  principles,  in 
contrast  to  the  sometimes  complex  and  subtle  sets  of  rules  assumed  by  the  BAN 
logic  and  related  belief  logics.  It  does  not,  however,  provide  the  same  high-level 
intuition  into  why  a  protocol  works  that  the  belief  logics  can.  Paulson  demon¬ 
strates  proof  tactics  that  can  be  applied  to  prove  some  lemmas  automatically,  but 
significant  human  interaction  still  appears  to  be  required. 

Brackin  has  recently  developed  a  system  within  HOL  for  converting  protocol 
specifications  in  an  extended  version  of  the  GNY  logic  [GNY90]  to  HOL  the¬ 
ories  [Bra96].  His  system  then  attempts  to  prove  user-specified  properties  and 
certain  default  properties  automatically.  This  work  looks  promising;  one  draw¬ 
back  is  that  it  is  tied  to  a  specific  logic.  Modifying  that  logic  or  applying  the 
technique  to  a  new  logic  would  require  substantial  effort  and  HOL  expertise.  In 
theory  generation,  the  logic  can  be  expressed  straightforwardly,  and  the  proving 
mechanism  is  independent  of  the  logic. 

Like  general-purpose  theorem  proving,  theory  generation  involves  manipula¬ 
tion  of  the  syntactic  representation  of  the  entity  we  are  verifying.  However,  by 
restricting  the  nature  of  the  logic,  unlike  machine-assisted  theorem  proving,  we 
can  enumerate  the  entire  theory  rather  than  (with  human  assistance)  develop  lem¬ 
mas  and  theorems  as  needed.  Moreover,  the  new  method  is  fast  and  completely 
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automatic,  and  thus  more  suitable  for  integration  into  the  protocol  development 
process. 


1.4.2  Belief  Logics 

For  reasoning  about  protocols  in  the  security  domain,  the  BAN  logic  and  its 
kin  have  attracted  significant  attention  in  recent  years  [BAN90,  GNY90,  KW94, 
Kai96,  Sv094].  This  work  diverges  from  the  algebraic  approach  to  cryptographic 
protocol  modeling  introduced  earlier  by  Dolev  and  Yao  [DY 8 1  ].  In  the  Dolev- Yao 
approach,  encryption  and  decryption  are  modeled  as  algebraic  transformations  on 
words,  and  reasoning  about  a  protocol  consists  of  proving  certain  words  do  not 
belong  to  the  language  corresponding  to  a  given  protocol.  The  BAN  family  em¬ 
phasizes  the  evolution  of  beliefs  by  participants  in  a  protocol. 

Burrows,  Abadi,  and  Needham  developed  their  logic  of  authentication  (BAN) 
around  the  notion  of  belief.  Each  message  in  a  protocol  is  represented  by  a  set  of 
beliefs  it  is  meant  to  convey,  and  principals  acquire  new  beliefs  when  they  receive 
messages,  according  to  a  small  set  of  rules.  The  BAN  logic  allows  reasoning 
not  just  about  the  authenticity  of  a  message  (the  identity  of  its  sender),  but  also 
about  freshness,  a  quality  attributed  to  messages  that  are  believed  to  have  been 
sent  recently.  This  allowed  BAN  reasoning  to  uncover  certain  replay  attacks  like 
the  well-known  flaw  in  the  Needham-Schroeder  shared-key  protocol  [DS81]. 

Several  other  logics  were  developed  to  improve  upon  BAN  by  providing  sup¬ 
port  for  different  cryptographic  operations  such  as  secure  hashes,  simplifying  the 
set  of  rules,  introducing  the  concept  of  a  recognizable  message,  and  other  such 
enhancements:  GNY  [GNY90],  SVO  [Sv094],  AUTLOG  [KW94],  and  Kailar’s 
accountability  logic  [Kai96]  are  some  of  the  more  prominent.  In  Chapters  3  and 
4  we  discuss  the  advantages  and  disadvantages  of  these  logics  further,  and  show 
how  theory  generation  can  be  applied  to  several  of  them.  The  Revere  system  de¬ 
scribed  in  Chapter  6  can  generate  “little  checkers”  for  these  logics  within  a  unified 
framework. 

There  has  been  some  other  work  on  modeling  security  protocols  with  more 
expressive  logics  that  are  somewhat  more  difficult  to  reason  with,  such  as  tem¬ 
poral  logics  and  the  nonmonotonic  logic  of  knowledge  and  belief  introduced  by 
Moser  [IM95,  Mos89].  Theory  generation  restricts  itself  to  a  simpler  class  of  log¬ 
ics  that  is  adequate  to  express  many  of  the  interesting  properties  of  these  protocols 
without  sacrificing  fully  automated  reasoning. 
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1.4.3  Model  Checking 

Model  checking  is  a  verification  technique  wherein  the  system  to  be  verified  is 
represented  as  a  finite  state  machine,  and  properties  to  be  checked  are  typically  ex¬ 
pressed  as  formulas  in  some  temporal  logic.  The  system  is  searched  exhaustively 
for  a  path  or  state  satisfying  the  given  formula  (or  its  complement).  The  process 
can  be  accelerated  greatly  through  symbolic  execution  and  the  use  of  compact 
representations  such  as  Binary  Decision  Diagrams  (BDDs)  [Bry86],  which  effi¬ 
ciently  encode  transition  relations  [BCM+90,  McM92].  Symbolic  model  check¬ 
ing  has  been  used  successfully  to  verify  many  concurrent  hardware  systems,  and 
it  has  attracted  significant  interest  in  the  wider  verification  community  due  to  its 
high  degree  of  automation  and  its  ability  to  produce  counterexamples  when  veri¬ 
fication  fails. 

Jonathan  Millen’s  Interrogator  tool  could  be  considered  the  first  model  checker 
for  cryptographic  protocol  analysis  [Mil84,  KMM94].  It  is  a  Prolog  [CM81]  sys¬ 
tem  in  which  the  user  specifies  a  protocol  as  a  set  of  state  transition  rules,  and 
further  specifies  a  scenario  corresponding  to  some  undesirable  outcome  (e.g.,  an 
intruder  learns  a  private  key).  The  system  then  searches,  with  Prolog  backtrack¬ 
ing,  for  a  message  history  matching  the  given  scenario.  If  such  a  history  is  found, 
the  Interrogator  has  demonstrated  a  flaw  in  the  protocol;  however,  if  no  matching 
message  history  is  found,  little  can  be  concluded.  The  construction  of  the  scenario 
and  protocol  specification  constrains  the  search  and  thus  may  cause  valid  attacks 
to  be  ignored. 

Recently,  advanced  general-purpose  model  checkers  have  been  applied  to 
protocol  analysis  with  some  encouraging  results.  Lowe  used  the  FDR  model 
checker  [Ros94]  to  demonstrate  a  flaw  in,  and  then  fix,  the  Needham-Schroeder 
public  key  protocol  [Low96]  and  (with  Roscoe)  the  TMN  protocol  [LR97],  and 
Roscoe  used  FDR  to  check  noninterference  of  a  simple  security  hierarchy  (high 
security/low  security)  [Ros95].  Heintze,  Tygar,  Wing,  and  Wong  used  FDR  to 
check  some  atomicity  properties  of  NetBill  [ST95]  and  Digicash  [CFN88]  pro¬ 
tocols  [HTWW96].  Mitchell,  Mitchell,  and  Stem  developed  a  technique  for  an¬ 
alyzing  cryptographic  protocols  using  Mur<£,  a  model-checker  that  uses  explicit 
state  representation,  and,  with  Shmatikov,  have  applied  it  to  the  complex  SSL 
protocol  [MMS97,  MSS98].  Finally,  Marrero,  Clarke,  and  Jha  have  produced 
a  specialized  model  checker  for  reasoning  about  security  protocols,  which  takes 
a  simple  protocol  specification  as  input  and  does  not  require  a  protocol-specific 
adversary  process  [CJM98]. 

Some  of  these  modem  model  checkers  borrow  from  the  semantic  model  in- 


8 


CHAPTER  1.  INTRODUCTION 


troduced  by  Woo  and  Lam  [WL93],  in  which  authentication  protocols  are  speci¬ 
fied  as  collections  of  processes  that  perform  sequences  of  actions  such  as  sending 
and  receiving  messages,  initiating  and  terminating  a  session,  and  creating  nonces. 
Correctness  properties  in  the  Woo-Lam  model  are  classified  as  secrecy  or  corre¬ 
spondence  properties.  The  correspondence  properties  link  actions  taken  by  two 
different  principals  in  a  protocol  run;  for  instance,  if  principal  Q  completes  a  pro¬ 
tocol  run  with  an  Endlnit  ( P )  action,  then  P  must  have  taken  a  BeginRespond  ( P ) 
action  earlier. 

All  these  model-checking  approaches  share  the  limitation  that  they  can  con¬ 
sider  only  a  limited  number  of  runs  of  a  protocol — typically  one  or  two — before 
the  number  of  states  of  the  finite  state  machine  becomes  unmanageable.  This  lim¬ 
itation  results  from  the  well-known  state  explosion  problem  exhibited  by  concur¬ 
rent  systems.  In  some  cases  it  can  be  worked  around  by  proving  that  any  possible 
attack  must  correspond  to  an  attack  using  at  most  n  protocol  runs. 

The  theory  generation  technique  takes  significant  inspiration  from  the  desir¬ 
able  features  of  model  checking.  Like  model  checking,  theory  generation  allows 
“push-button”  verification  with  no  lemmas  to  postulate  and  no  invariants  to  infer. 
Whereas  model  checking  achieves  this  automation  by  requiring  a  finite  model, 
theory  generation  achieves  it  by  requiring  a  simple  logic.  Also  like  model  check¬ 
ing,  theory  generation  seeks  to  provide  more  interesting  feedback  than  a  simple 
“yes,  this  property  holds”  or  “I  cannot  prove  this  property.”  In  model  checking, 
counterexamples  give  concrete  illustrations  of  failures,  while  theory  generation 
offers  the  opportunity  to  directly  examine  and  compare  theories  corresponding  to 
various  protocols.  By  taking  advantage  of  the  intuitive  belief  logics,  theory  gen¬ 
eration  can  better  provide  the  user  with  a  sense  of  why  a  protocol  works  or  how  it 
might  be  improved;  model  checking  is  more  of  a  “black  box”  in  this  respect.  The 
two  approaches  can  complement  each  other,  as  model  checking  provides  answers 
without  specifying  belief  interpretations  for  the  protocol,  while  theory  generation 
presents  the  user  with  a  higher-level  view  of  the  protocol’s  effects. 

1.4.4  Hybrid  Approaches 

Meadows’  NRL  Protocol  Analyzer  is  perhaps  the  best  known  tool  for  computer- 
assisted  security  protocol  analysis  [Mea94].  It  is  a  semi-automated  tool  that  takes 
a  protocol  description  and  a  specification  of  some  bad  state,  and  produces  the  set 
of  states  that  could  immediately  precede  it.  In  a  sense  the  Analyzer  represents  a 
hybrid  of  model  checking  and  theorem  proving  approaches:  it  interleaves  brute- 
force  state  exploration  with  the  user-guided  derivation  of  lemmas  to  prune  the 
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search  space.  It  has  the  notable  advantages  that  it  can  reason  about  parallel  proto¬ 
col  run  attacks  and  that  it  produces  sample  attacks,  but  it  sometimes  suffers  from 
the  state  explosion  problem  and  it  requires  significant  manual  guidance.  It  has 
been  applied  to  a  number  of  security  protocols,  and  continuing  work  has  increased 
the  level  of  automation  [Mea98],  Theory  generation,  however,  offers  greater  au¬ 
tomation,  the  benefits  of  intuitive  belief  logics,  and  protocol  comparison  abilities 
not  available  in  the  Analyzer. 

While  not  a  protocol  analysis  approach  in  its  own  right,  the  Common  Authen¬ 
tication  Protocol  Specification  Language  (CAPSL)  [Mil97]  plays  an  important 
role  in  this  field.  Developed  by  Millen  in  cooperation  with  other  protocol  analysis 
researchers,  CAPSL  is  intended  to  provide  a  unified  notation  for  describing  proto¬ 
cols  and  their  accompanying  assumptions  and  goals.  It  captures  and  standardizes 
notions  shared  by  most  modem  protocol  analysis  techniques:  principals,  encryp¬ 
tion,  nonces,  freshness,  concatenation,  and  so  forth,  but  it  also  allows  modular 
extensions  for  expressing  user-specified  abstractions.  As  more  analysis  tools  are 
constructed  to  CAPSL,  it  should  become  easier  to  share  protocol  specifications 
among  different  tools,  and  more  practical  to  develop  and  use  specialized  tools  for 
an  integrated  analysis. 

1.4.5  Logic  Programming  and  Saturation 

Theory  generation  shares  some  elements  with  logic  programming,  as  embodied 
in  programming  languages  like  Prolog.  Through  careful  use  of  Prolog  backtrack¬ 
ing,  one  can  enumerate  derivable  formulas  to  produce  results  similar  to  those  of 
theory  generation.  Automated  reasoning  with  AUTLOG  has  been  implemented  in 
Prolog,  and  similar  techniques  could  probably  be  applied  to  automate  a  variety  of 
belief  logics.  We  encoded  the  BAN  logic  in  Prolog,  but  found  that  the  encoding 
was  very  sensitive  to  the  ordering  of  rules  and  required  hand-tuning  to  ensure  ter¬ 
mination.  Reasoning  via  theory  generation  is  more  general  in  that  we  can  produce 
results  and  guarantee  termination  without  any  dependence  on  rale  ordering,  and 
because  we  use  a  modified  unification  algorithm  that  can  handle  simple  rewrite 
rules.  At  the  same  time,  it  is  more  specific;  by  tailoring  our  reasoning  to  a  spe¬ 
cific  domain— these  “little”  belief  logics— -we  exploit  the  nature  of  the  domain  in 
ways  that  make  exhaustive  enumeration  a  computationally  feasible  and  tractable 
approach  to  automatic  verification. 

The  idea  of  computing  a  finite  “closure”  (or  “completion”)  of  a  theory  is  used 
in  the  theorem  proving  system  SATURATE  [NN93].  SATURATE  takes  a  set  of 
first-order  logic  formulas  and  attempts  to  compute  a  finite  set  of  formulas  that 
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represents  the  saturated  theory  induced  by  those  axioms.  This  saturated  theory 
is  a  set  of  deduced  clauses  without  redundancy,  where  a  clause  is  redundant  if  it 
is  entailed  by  smaller  clauses  in  the  set.  If  it  succeeds,  the  theory  is  guaranteed 
to  be  consistent,  and  the  saturated  set  can  be  used  to  create  a  decision  procedure 
for  the  theory.  Our  restrictions  on  the  input  logic  allow  us  to  generate  a  saturated 
set  of  formulas  that  we  find  easier  to  interpret  than  the  sets  generated  by  this  more 
general  system.  The  primary  purposes  of  the  completion  computed  by  SATURATE 
are  to  provide  a  demonstration  that  the  input  theory  is  consistent,  and  to  allow  a 
fast  decision  procedure  to  operate  on  the  saturated  theory.  We  choose  to  empha¬ 
size  different  uses  for  the  finite  sets — in  particular,  direct  analysis  and  comparison 
of  these  sets.  In  addition,  the  restricted  framework  we  adopt  frees  the  user  from 
worrying  about  termination;  Saturate  accepts  a  broader  range  of  inputs  and 
thus  cannot  ensure  that  the  completion  operation  will  halt.  In  limited  experiments 
applying  Saturate  to  the  BAN  logic,  we  were  unable  to  find  a  configuration  in 
which  saturation  would  terminate  on  most  trials. 


1.5  Road  Map 

In  the  remainder  of  this  dissertation,  we  describe  the  theory  and  practice  of  the¬ 
ory  generation  for  security  protocol  verification.  In  Chapter  2  we  describe  theory 
generation  formally  and  present  an  algorithm  for  performing  theory  generation. 
Chapter  3  presents  theory  generation  as  applied  with  existing  belief  logics  to  an¬ 
alyze  various  protocols.  In  Chapter  4  we  develop  a  new  belief  logic,  RV,  whose 
explicit  notion  of  interpretation  yields  significant  advantages  over  existing  belief 
logics.  In  Chapter  5  we  lay  out  a  step-by-step  method  for  doing  more  comprehen¬ 
sive  protocol  verification  with  RV,  with  sample  applications  to  several  protocols. 
Discussion  of  practical  issues  arising  in  the  implementation  of  the  theory  gener¬ 
ation  algorithm  appears  in  Chapter  6,  along  with  a  description  of  the  Revere 
protocol  verification  tool  and  some  performance  benchmarks.  Finally,  Chapter  7 
contains  reflections  on  the  contributions  of  this  work  and  directions  for  future 
research. 


Chapter  2 

Theory  Generation 


When  working  with  a  logic,  whether  for  program  verification,  planning,  diagno¬ 
sis,  or  any  other  purpose,  a  natural  question  to  ask  is,  “What  conclusions  can  we 
derive  from  our  assumptions?”  Given  a  logic,  and  some  set  of  assumptions,  T°, 
we  consider  the  complete  theory,  T*,  induced  by  T°.  Also  known  as  the  conse¬ 
quence  closure ,  T*  is  simply  the  (possibly  infinite)  set  of  formulas  that  can  be 
derived  from  T°,  using  the  rules  and  axioms  of  the  logic.  We  typically  explore 
T*  by  probing  it  at  specific  points:  “Can  we  derive  formula  FI  What  about  GT’ 
Sometimes  we  test  whether  T*  contains  every  formula;  that  is,  whether  the  theory 
is  inconsistent.  It  is  interesting,  however,  to  consider  whether  we  can  character¬ 
ize  T*  more  directly,  and  if  so  what  benefits  that  might  bring.  In  the  following 
sections,  we  explore  for  a  special  class  of  logics  a  general  way  of  representing 
T*  and  a  technique,  called  theory  generation,  for  mechanically  producing  that 
representation. 

2.1  Logics 

Theory  generation  may  in  principle  be  applied  to  any  logic,  but  in  this  chapter  we 
consider  only  those  falling  within  a  simple  fragment  of  first-order  logic.  We  start 
by  defining  briefly  the  standard  components  of  first-order  logic.  More  complete 
treatments  may  be  found  in  introductory  logic  texts  [Bar77], 

Definition  2.1  A  first-order  language,  L,  is  a  possibly  infinite  set  of  variables, 
constants,  function  symbols,  and  predicate  symbols. 

In  this  chapter,  we  will  use  X  and  Y  for  variables;  S  and  T  for  terms;  F,  G,  P,  C , 
and  (f)  for  formulas;  and  /,  g,  and  p  for  function  and  predicate  symbols. 
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Definition  2.2  The  set  of  terms  of  L  is  the  smallest  set  such  that  every  variable 
is  a  term,  and  every  expression  /(Ti, . . .  ,Tn)  is  a  term,  where  f  is  a  function 
symbol,  T±, ...  ,Tn  are  terms,  and n  >  0. 

Definition  23  The  well-formed  formulas  (wffsj  are  built  from  terms  as  follows: 

•  p(Ti Tn)  is  a  wff  ifTi,...,Tn  are  terms  and  p  is  a  predicate  symbol 
(for  any  n  >  0); 

•  VX.F  is  a  wff  if  X  is  a  variable  and  F  is  a  wff;  and 

•  (-i F)  and  (F  =>  G)  are  wffs  if  F  and  G  are  wffs.  • 1 

The  other  propositional  connectives  (V,  A,  <*=>  )  and  the  existential  quantifier 
(3)  may  be  used  as  abbreviations  for  their  equivalents  in  terms  of  V,  -i,  and  =*►. 

In  first-order  logic  with  equality,  the  set  of  wffs  above  is  extended  to  include 
all  formulas  of  the  form 

S  ==T 

where  S  and  T  are  terms. 

We  restrict  our  attention  to  the  fragment  of  first-order  logic  we  call  £,  defined 
here.  (We  use  X  as  a  shorthand  for  X\, . . . ,  X^.) 

Definition  2.4  The  logic,  C,  is  that  fragment  of  first-order  logic  whose  well- 
formed  formulas  are  all  of  the  following  form: 


VX.((Pj  A  P2  A  •  •  •  A  Pm)  =►  C) 

where  m  >  0,  n  >  0,  the  Pi  and  C  are  formulas  containing  no  connectives  or 
quantifiers,  and  X  are  all  the  free  variables  occurring  in  those  formulas. 

For  formulas  of  £  in  which  m  =  0,  the  standard  form  reduces  to 


VX.C 


(2.1) 


We  will  sometimes  interpret  formulas  of  £  (in  which  m  >  0)  as  rules  of  inference, 
writing  them  in  this  form: 


Pi 


(2.2) 


Note  that  this  class  of  formulas  is  equivalent  to  Horn  clauses.  We  will  normally 
refer  to  formulas  in  the  forms  of  (2.1)  and  (2.2)  as  assumptions  and  rules  respec¬ 
tively.  (In  Prolog  terminology,  these  are  facts  and  rules.)  We  reserve  the  term 
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rules  of  inference  to  refer  specifically  to  the  inference  rules  for  C  itself  (such  as 
modus  ponens,  below). 

We  will  also  consider  an  extension  of  C  that  includes  a  limited  form  of  equal¬ 
ity: 

Definition  2.5  The  logic,  Cr,  is  the  fragment  of  first-order  logic  with  equality 
whose  well-formed  formulas  include  all  the  wffs  of  C,  as  well  as  formulas  of  this 
form: 

VX.(S  =  T)  (2.3) 

where  S  and  T  are  terms,  and  the  Xi  are  all  the  free  variables  occurring  in  S  and 
T. 

We  call  these  universally-quantified  equalities  rewrites. 

We  will  use  Hilbert-style  axioms  and  rules  of  inference  for  first-order  logic. 
The  axioms  include 

•  all  propositional  tautologies, 

•  all  formulas  of  the  form 

(Vx.<f>($))  =>  <p(t) 

where  x  is  any  variable  and  t  any  term,  and 

•  for  first-order  logic  with  equality,  the  standard  equality  axioms: 

-  (T  =  T)  (reflexivity), 

-  (S  —  T)  =>  (T  =  S)  (commutativity), 

-  ((7i  —  T2)  A  (Ta  —  Ts))  =>  (Ti  -  Tf)  (transitivity), 

-  (Si  ==  Ti  A  •  ■  -  A  Sn  ss  Tn)  =*>  (p(Si,  ...,Sn)=$  p(Ti, . . . ,  Tn)),  and 

-  (Si  Ti  A  *  •  •  A  Sn  =  Tn) 

([Si\Xi,  ....  Sn\Xn]t  -  [Ti\Xi, .  .  .  ,  Tn\Xn]t) 

(The  notation  [5i\Xi, . . . ,  Sn\Xn]t  denotes  the  term  obtained  by  substitut¬ 
ing  Si  for  free  occurrences  of  Xi  in  t,  S%  for  Xi ,  and  so  on.) 

The  rules  of  inference  are  modus  ponens: 

(F^G)  F 
G 
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and  the  generalization  rule: 


F=>G 

F  =>•  \/y\y\x)G 


(where  x  is  not  free  in  F). 

Given  these  axioms  and  rules  of  inference,  we  can  define  the  formal  notion  of 
proof: 

Definition  2.6  A  proof  of  some  formula  F  from  a  set  of  assumptions  T  is  a  finite 
sequence,  {Fi, . . . ,  Fn},  of  formulas,  where  Fn  is  F,  and  each  element  Fi  is  either 
an  axiom  instance,  a  member  ofT,  or  the  result  of  an  application  of  one  of  the 
rules  of  inference  using  formulas  in  Fi, . . . ,  Fj-j. 

We  say  a  formula  F  is  derivable  from  T  (written  T  h  F)  if  a  proof  of  F  from  T 
exists. 

We  now  introduce  a  class  of  “little  logics”  that  are,  in  a  way,  equivalent  to  Cr, 
parameterized  by  a  fixed  set  of  rules  and  rewrites: 

Definition  2.7  The  logic,  £rw,  where  R  is  a  set  of  rules  in  the  form  of  (2.2),  and 
W  is  a  set  of  rewrites  in  the  form  of  (2.3),  has  as  its  formulas  all  connective-free 
formulas  of  C.  The  rules  of  inference  of  £rw  are  all  the  rules  in  R,  as  well  as 
instantiation,  and  substitution  of  equal  terms  using  the  rewrites  in  W. 

Proofs  in  £rw  are  thus  finite  sequences  of  formulas  in  which  each  formula  is  either 
an  assumption,  an  instance  of  an  earlier  formula,  the  result  of  applying  one  of  the 
rules  in  R,  or  the  result  of  a  replacement  using  a  rewrite  in  W. 

The  following  theorem  shows  the  correspondence  between  £rw  and  £=; 

Theorem  2.1  If  (f>  is  a  formula  of  £rw,  and  T  is  a  set  of  formulas  of  £rw,  then 

r  l"W  4> 


if  and  only  if 

ruflUWbc-  <t> 

That  is,  proof  in  £rw  is  equivalent  to  proof  in  Cr  using  the  same  rules  and  rewrites 
(R  and  W).  The  proof  of  this  theorem  is  long  but  fairly  mechanical;  it  appears  in 
Appendix  A. 

Finally,  we  define  the  notion  of  theory  (also  known  as  consequence  closure ): 


2.2.  THEORY  REPRESENTATION 


15 


Definition  2.8  Let  L  be  a  logic,  and  T°  a  set  ofwffs  in  that  logic,  T*,  the  theory 
induced  by  T°,  is  the  possibly  infinite  set  ofwffs  containing  exactly  those  wffs  that 
can  be  derived  from  T°  and  the  axioms  of  L,  using  the  rules  of  L. 

T*  is  closed  with  respect  to  inference,  in  that  every  formula  that  can  be  derived 
from  T*  is  a  member  of  T*.  In  the  following  sections,  we  consider  theories  in  the 
context  of  £rw  logics  and  show  how  to  generate  representations  of  those  theories. 


22  Theory  Representation 

The  goal  of  theory  generation  is  to  produce  a  finite  representation  of  the  theory 
induced  by  some  set  of  assumptions;  in  this  section  we  consider  the  forms  this 
representation  might  take,  and  the  factors  that  may  weigh  in  favor  of  one  repre¬ 
sentation  or  another.  These  factors  will  be  determined  in  part  by  the  purposes 
for  which  we  plan  to  use  the  representation.  There  are  three  primary  uses  for  the 
generated  theory  representation: 

•  It  may  be  used  in  a  decision  procedure  for  determining  the  derivability  of 
specific  formulas  of  interest  (see  Section  2.4). 

•  It  may  be  manipulated  and  examined  by  a  human  through  assorted  filters, 
in  order  to  gain  insight  into  the  nature  of  the  complete  theory. 

•  It  may  be  directly  compared  with  the  representation  of  some  other  theory, 
to  reveal  differences  between  the  two  theories. 

These  applications  are  discussed  in  greater  detail  in  Chapter  5. 

The  full  theory  is  a  possibly  infinite  set  of  formulas  entailed  by  some  initial 
assumptions,  so  the  clearest  requirement  of  the  representation  we  generate  is  that 
it  be  finite.  A  natural  way  to  achieve  this  is  to  select  a  finite  set  of  “representative 
formulas”  that  belong  to  the  theory,  and  let  this  set  represent  the  full  theory.  Other 
approaches  are  conceivable;  we  could  construct  a  notation  for  expressing  certain 
infinite  sets  of  formulas,  perhaps  analogous  to  regular  expressions  or  context-free 
grammars.  However,  the  logic  itself  is  already  quite  expressive;  indeed,  the  set  of 
initial  assumptions  and  rules  “expresses”  the  full  theory  in  some  sense.  There  is 
no  clear  benefit  of  creating  a  separate  language  for  theory  description. 

Given  that  we  choose  to  represent  a  theory  by  selecting  some  subset  of  its 
formulas,  it  remains  to  decide  what  subset  is  best.  Here  are  a  few  informal  criteria 
that  may  influence  our  choice: 
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Cl.  The  set  of  formulas  must  be  finite,  and  should  be  small  enough  to  make 
direct  manipulation  practical.  An  enormous,  though  finite,  set  would  prob¬ 
ably  be  not  only  inefficient  to  generate,  but  unsuitable  for  examination  by  a 
human  except  through  very  fine  filters. 

C2.  There  should  be  an  algorithm  that  generates  the  set  with  reasonable  effi¬ 
ciency. 

C3.  Given  an  already-generated  set,  there  should  be  an  efficient  decision  proce¬ 
dure  for  the  full  theory,  using  that  set.  Since  the  simplest  way  to  characterize 
a  theory  is  to  test  specific  formulas  for  membership,  a  quick  decision  pro¬ 
cedure  is  important. 

C4.  The  set  should  be  canonical.  For  a  given  set  of  initial  assumptions,  the 
generated  theory  representation  should  be  uniquely  determined.  This  makes 
direct  comparison  of  the  sets  more  useful. 

C5.  The  set  should  include  as  many  of  the  “interesting”  formulas  in  the  theory 
as  possible,  and  as  few  of  the  “uninteresting”  ones  as  possible.  For  instance, 
when  a  large  class  of  formulas  exists  in  the  theory,  but  all  represent  essen¬ 
tially  the  same  fact,  it  might  be  best  for  the  theory  representation  to  include 
only  the  simplest  formula  from  this  class.  This  will  enable  humans  to  glean 
useful  information  from  the  generated  set  without  sifting  through  too  much 
chaff. 

Ganzinger,  Nivela,  and  Niewenhuis’s  SATURATE  prover  takes  one  approach  to 
this  problem  [NN93],  Saturate  is  designed  to  work  with  a  very  general  logic: 
full  first-order  logic  over  transitive  relations.  It  can,  under  some  circumstances, 
produce  a  finite  “saturated  theory”  that  enables  an  efficient  decision  procedure. 
The  saturation  process  can  also  be  used  to  check  the  consistency  of  a  set  of  for¬ 
mulas,  since  false  will  appear  in  the  saturated  set  if  the  original  set  is  inconsistent. 
The  price  Saturate  pays  for  its  generality  is  that  saturation  is  not  guaranteed 
to  terminate  in  all  cases;  there  are  a  number  of  user-tunable  parameters  that  con¬ 
trol  the  saturation  process  and  make  it  more  or  less  thorough  and  more  or  less 
likely  to  terminate.  This  flexibility  is  sometimes  necessary,  but  we  choose  to  fo¬ 
cus  on  more  limited  logics  in  which  we  can  make  stronger  guarantees  regarding 
termination  and  require  less  assistance  from  the  user. 

For  iftw  logics,  we  select  a  class  of  theory  representations  we  refer  to  as 
(R,  R')  representations : 
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Definition  2,9  From  the  set  of  rules,  R,  choose  some  subset,  R'.  An  (R,  R!)  rep¬ 
resentation  of  the  theory  induced  by  T°  contains  a  set  of  formulas  derivable  from 
T°,  such  that  any  proof  from  the  assumptions,  T°,  in  which  the  last  rule  applica¬ 
tion  (if  any)  is  an  application  of  some  rule  in  R!,  the  conclusion  of  that  proof  is 
equivalent  to  some  formula  in  the  set.  Furthermore,  every  formula  in  the  set  is 
equivalent  to  the  conclusion  of  some  such  proof.  Finally,  no  two  formulas  in  the 
set  are  equivalent. 

In  this  formulation,  the  rules  in  R!  are  “preferred”  in  that  they  are  applied  as  far 
as  possible.  The  equivalence  used  in  this  definition  may  be  strict  identity  or  some 
looser  equivalence  relation.  We  can  test  a  formula  for  membership  in  the  full 
theory  by  using  the  theory  representation  and  just  the  rules  in  (R  —  R!)  (this  is 
proved  in  Section  2.4),  This  can  be  significantly  more  efficient  than  the  general 
decision  problem  using  all  of  R,  so  criterion  C3  can  be  satisfied.  If  we  select  the 
representation  to  include  only  one  canonical  formula  from  any  equivalence  class, 
then  the  representation  is  completely  determined  by  T°,  R,  and  R1,  so  criterion  C4 
is  satisfied. 

In  order  to  satisfy  the  remaining  criteria  (Cl,  C2,  and  C5),  we  must  choose 
R!  carefully.  We  could  choose  R!  =  {},  but  the  resulting  theory  representation 
would  just  be  T°,  the  initial  assumptions:  unlikely  to  enable  an  efficient  decision 
procedure  and  certainly  not  very  “interesting”  (in  the  sense  of  C5).  For  some  sets 
of  rules,  we  could  let  R!  =  R,  but  in  many  cases  this  would  yield  an  infinite  repre¬ 
sentative  set,  violating  Cl.  In  the  next  section  we  describe  a  method  for  selecting 
R!  that  is  guaranteed  to  produce  a  finite  representative  set,  and  that  satisfies  the 
remaining  criteria  in  practice. 


2.3  The  Theory  Generation  Algorithm,  TG^ 

In  an  Irw  logic,  as  defined  in  Section  2.1,  we  can  automatically  generate  a  finite 
representation  of  the  theory  induced  by  some  set  of  formulas,  F,  provided  the 
logie  and  the  formulas  in  T  satisfy  some  additional  restrictions.  In  the  following 
section,  we  describe  these  preconditions  and  explain  how  they  can  be  checked. 
Section  2.3.2  contains  a  description  the  algorithm  itself,  which  is  followed  by 
proofs  of  its  correctness  and  termination  in  Sections  2.3.3  and  2.3.4. 
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2.3.1  Preconditions 

In  order  to  apply  our  theory  generation  algorithm,  TG^,  to  a  logic,  £rw,  and  a 
set  of  assumptions,  T,  some  preconditions  on  the  rules  and  rewrites  (R  and  W)  of 
£rw,  and  on  I\  must  hold.  These  preconditions  require  that  the  set  of  rules  (R)  can 
be  partitioned  into  S-rules  and  G-rules,  that  the  rewrites  (W)  be  size-preserving, 
and  that  the  formulas  in  T  be  mostly-ground.  Informally,  the  S-rules  are  “shrinking 
rules,”  since  they  tend  to  produce  conclusions  no  larger  than  their  premises,  and 
the  G-rules  are  “growing  rules”  since  they  have  the  opposite  effect.  The  S-rules 
are  the  principal  rules  of  inference;  in  the  generated  theory  representation,  they 
will  be  treated  as  the  preferred  rules  (the  R!  set  in  an  (R,  R')  representation).  We 
define  these  terms  and  formally  present  the  preconditions  in  this  section. 

The  TGf  algorithm  repeatedly  applies  rules,  starting  from  the  assumptions,  to 
produce  an  expanding  set  of  derivable  formulas.  The  basic  intent  of  these  precon¬ 
ditions  is  to  limit  the  ways  in  which  formulas  can  “grow”  through  the  application 
of  rules.  As  long  as  the  process  of  applying  rules  cannot  produce  formulas  larger 
than  the  ones  we  started  with,  we  can  hope  to  reach  a  fixed  point,  where  no  further 
application  of  the  rules  can  yield  a  new  formula.  The  algorithm  eagerly  applies 
the  S-rules  to  the  assumptions  as  far  as  possible,  using  the  G-rules  and  rewrites 
only  as  necessary.  The  restrictions  below  ensure  first  that  the  algorithm  can  find  a 
new  S-rule  application  in  a  finite  number  of  steps,  and  second  that  each  new  for¬ 
mula  derived  is  smaller  than  some  already-known  formula,  so  the  whole  process 
will  terminate. 

The  preconditions  below  are  defined  with  respect  to  a  pre-order  (a  reflexive 
and  transitive  relation)  on  terms  and  formulas,  ■<.  This  pre-order  may  be  defined 
differently  for  each  application  of  the  algorithm,  but  it  must  always  satisfy  these 
conditions: 

PI.  The  pre-order  must  be  monotonic;  that  is, 

m  ^  T2)  =*  ([TAX] F  d  [T2\X]F) 

P2.  The  pre-order  must  be  preserved  under  substitution: 

(F  X  G)  ([T\X]F  ^  [T\X]G) 

P3.  The  set  {F  |  F  ■<  G}  must  be  finite  (modulo  variable  renaming)  for  all 
formulas  G.  This  is  a  form  of  well-foundedness. 
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Intuitively,  F  <G  means  that  the  formula  F  is  no  larger  than  G;  with  this  inter¬ 
pretation,  condition  P3  means  that  there  are  only  finitely  many  formulas  no  larger 
than  G.  In  Chapter  3,  we  construct  a  specific  ■<  relation  satisfying  these  condi¬ 
tions,  which  can  be  used  with  only  minor  variations  in  a  variety  of  situations. 

If  there  exists  some  such  H  under  which  the  preconditions  below  are  met,  then 
the  TGf  algorithm  can  be  applied  to  £rw  and  F. 

We  can  weaken  the  condition  P3  above  slightly,  to  allow  broader  application 
of  the  algorithm.  We  introduce  a  syntactic  constraint  on  formulas,  represented  as  a 
set  of  formulas,  C.  Every  assumption  in  F  must  be  in  C,  and  C  must  be  closed  over 
all  the  rules  and  rewrites  (that  is,  when  applied  to  formulas  in  C,  rules  and  rewrites 
must  yield  conclusions  in  C).  Furthermore,  applying  a  substitution  to  a  formula  in 
C  must  always  yield  another  formula  in  C.  We  can  then  allow  a  pre-order  ■<  for 
which  P3  above  may  not  hold  but  P3'  does: 

P3'.  The  set  {F  £  C  |  F  <  G}  must  be  finite  (modulo  variable  renaming)  for  all 
formulas  G. 

In  describing  the  preconditions,  we  use  a  notion  of  mostly-ground  formulas: 

Definition  2.10  A  formula,  F,  is  mostly-ground  with  respect  to  a  pre-order,  ■<, 
and  some  syntactic  constraint,  C,  if 

Ver,  (oF  £  C  =£•  crF  ^  F) , 

where  a  ranges  over  substitutions.  That  is,  every  instance  of  F  that  meets  the 
syntactic  constraint  is  no  larger  than  F  itself. 

Any  ground  (variable-free)  formula  is  trivially  mostly-ground.  For  some  defini¬ 
tions  of  ■<  and  some  constraints  on  formulas,  however,  certain  formulas  contain¬ 
ing  variables  may  also  be  mostly-ground.  Chapter  3  contains  such  an  example, 
in  which  C  limits  the  possible  values  for  some  function  arguments  to  a  finite  set. 
Note  that,  as  a  consequence  of  P3',  there  exist  only  a  finite  number  of  instances 
(modulo  variable  renaming)  of  any  mostly-ground  formula.  The  preconditions  re¬ 
quire  that  every  formula  in  T  be  mostly-ground,  in  order  to  limit  the  number  of 
new  formulas  that  can  be  derived  through  simple  instantiation. 

Before  proceeding  with  the  preconditions,  we  need  to  define  unification  mod¬ 
ulo  rewrites  briefly: 

Definition  2.11  Formulas  F\  and  F2  can  be  unified  modulo  rewrites  if  and  only 
if  there  exists  a  substitution,  a,  of  terms  for  variables  such  that 

W  =£•  {jjF\  =  oFf) 
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where  W  is  the  set  of  all  rewrites.  The  substitution  a  is  called  a  unifier  for  F\  and 
F2. 

With  this  definition,  if  F\  and  F2  can  be  unified  modulo  rewrites,  then  we  can 
prove  F2  from  Fx  by  applying  instances  of  zero  or  more  rewrites.  Except  where 
explicitly  noted,  unification  is  always  assumed  to  be  modulo  rewrites. 

Now  we  define  the  allowed  classes  of  rules  in  R:  S-rules  and  G-rules. 

Definition  2.12  An  S-rule  (shrinking  rule)  is  a  rule  in  which  some  subset,  pri,  of 
the  Pi  (premises)  are  designated  " primary  premises,”  and  for  which  the  conclu¬ 
sion,  C,  satisfies 

3  Pepri.{C<P). 

That  is,  for  an  S-rule,  the  conclusion  is  no  larger  than  some  primary  premise.  We 
call  the  non-primary  premises  side  conditions.  The  premises  of  an  S-rule  may  be 
partitioned  into  primary  premises  and  side  conditions  in  any  way  such  that  this 
condition  holds,  and  the  S/G  restriction  (described  later)  is  also  satisfied. 

The  G-rules  are  applied  only  as  necessary,  so  it  is  safe  for  them  to  yield  for¬ 
mulas  larger  than  their  premises.  In  fact,  it  is  required  that  the  G-rules  “grow”  in 
this  way,  so  that  backward  chaining  with  them  will  terminate. 

Definition  2.13  A  G-rule  (growing  rule)  is  a  rule  for  which 


VA;.(Pfc  ^  C) 

In  a  G-rule,  the  conclusion  is  at  least  as  large  as  any  premise. 

The  rewrites  are  intended  to  provide  simple  transformations  that  have  no  effect 
on  the  size  of  a  formula.  They  are  often  useful  for  expressing  associativity  or 
commutativity  of  certain  functions  in  the  logic.  The  preconditions  require  that  all 
rewrites  (the  set  W)  be  size-preserving: 

Definition  2.14  A  rewrite, 

VX.(S  —  T) , 

is  size-preserving  if  S  -<T  and  T  ■<  S. 

From  this  definition  and  pre-order  conditions  PI  and  P2,  it  follows  immediately 
that  if  we  apply  a  rewrite  to  a  formula,  F,  producing  F',  then 

VG.(G*F)  «=►  (G  *  F') 
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and 

VC?.(F  X  G)  (F1  <  G )  . 

That  is,  the  rewrite  has  not  affected  the  ‘‘size”  of  F. 

Finally,  to  guarantee  termination,  the  algorithm  requires  that  the  S/G  restric¬ 
tion  hold  for  each  S-rule: 

Definition  2.15  S/G  restriction:  Given  an  S-rule  with  primary  premises  Pi,  side 
conditions  Si,  and  conclusion  C, 

•  each  primary  premise  Pi  must  not  unify  with  any  G-rule  conclusion,  and 

•  each  side-condition.  Si,  must  satisfy  Si  ^  C. 

Note  that  this  restriction  constrains  the  manner  in  which  S-  and  G-rules  can  inter¬ 
act  with  each  other.  Whereas  the  other  restrictions  are  local  properties  and  thus 
can  be  checked  for  each  rule,  rewrite,  and  assumption  in  isolation,  this  global  re¬ 
striction  involves  all  rules  and  rewrites.  It  can,  however,  be  checked  quickly  and 
automatically.  Along  with  the  S-rule  definition,  this  restriction  defines  the  role 
of  the  side  conditions:  unlike  the  primary  premises,  whose  instantiations  largely 
determine  the  form  of  the  S-rule’s  result,  the  side  conditions  serve  mainly  as  qual¬ 
ifications  that  can  prevent  or  enable  a  particular  application  of  the  S-rule. 

We  can  now  define  the  full  precondition  that  ensures  the  TG^  algorithm  will 
succeed  with  a  given  set  of  inputs. 

Definition  2.16  The  TG^  precondition  holds  for  some  finite  sets  of  assumptions 
(V),  rules  (R),  and  rewrites  (W);  some  syntactic  constraint  (C);  and  some  pre¬ 
order  (-<),  if  and  only  if  all  of  the  following  are  true: 

•  The  pre-order,  <,  satisfies  conditions  PI,  P2,  and  PS'  (given  C). 

•  Every  formula  in  T  is  mostly-ground,  with  respect  to  ■<. 


•  Every  rule  in  R  is  either  a  G-rule  or  an  S-rule,  with  respect  to  <. 


•  Every  rewrite  in  W  is  size-preserving,  with  respect  to  <■ 

•  The  S/G  restriction  holds  for  each  S-rule  in  R 

Given  a  pre-order,  <,  that  is  computable  and  satisfies  the  P1-P3'  conditions, 
and  a  test  for  mostly-groundness  corresponding  to  •<,  it  is  possible  to  check  the 
last  four  components  of  this  precondition  automatically.  The  partitioning  of  the 
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rules  into  S-  and  G-rules  may  not  be  completely  determined  by  the  definitions 
above.  If  a  rule  has  no  premise  larger  than  its  conclusion,  and  the  conclusion 
no  larger  than  any  premise,  it  could  go  into  either  category.  In  some  cases,  the 
S/G  restriction  may  determine  the  choice,  but  in  others  it  must  be  made  arbitrarily 
or  at  the  user’s  suggestion.  (A  rule  whose  conclusions  are  rarely  interesting  in 
their  own  right  should  probably  be  designated  a  G-rule.)  The  S-rules’  primary 
premises  can  be  identified  automatically  as  those  premises  that  match  no  G-rule 
conclusions. 

There  are  Irw  logics  for  which  regardless  of  the  <  pre-order  chosen,  the  TG^ 
preconditions  cannot  hold.  Here  is  one  such  logic: 


B1  .  9(f PO) 

R1'W 


R2  : 


g(X)  ‘ 

9(f(X)) 


(There  are  no  rewrites  or  syntactic  constraints.)  To  see  why  this  logic  can  never 
meet  the  TGf  preconditions,  consider  first  the  case  that  R1  is  an  S-rule.  Since 
Rl’s  premise  matches  the  conclusion  of  R2,  it  follows  that  R2  must  also  be  an 
S-rule  or  the  S/G  restriction  would  fail.  Since  R2  is  an  S-rule,  that  implies  that  its 
conclusion  is  no  larger  than  its  premise: 


»(/(*))  r<  g(X) 

By  pre-order  condition  P2  and  reflexivity  of  pre-orders,  all  formulas  of  the  form, 
9{f  (/(•■■/ (X)))),  are  r<  g{X).  Since  there  are  infinitely  many  such  formulas, 
pre-order  condition  P3  is  violated,  so  we  have  a  contradiction,  and  R1  must  not 
be  an  S-rule.  The  only  other  possibility  is  that  R1  is  a  G-rule,  From  the  G-rule 
definition,  though,  we  have 


9(f(X))  <  g{X) 

which,  again,  is  impossible,  so  this  pair  of  rules  is  unusable  with  TG*. 

2.3.2  The  Algorithm 

The  theory  generation  algorithm,  TG^,  essentially  consists  of  performing  forward 
chaining  with  the  S-rules  starting  from  the  assumptions,  with  backward  chain¬ 
ing  at  each  step  to  satisfy  S-rule  premises  using  G-rules  and  rewrites.  Forward 
chaining  is  the  repeated  application  of  rules  to  a  set  of  known  formulas,  adding 
new  known  formulas  to  this  set  until  a  fixed  point  is  reached.  Backward  chaining 
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is  the  process  of  searching  for  a  derivation  of  some  desired  formula  by  applying 
rules  “in  reverse,”  until  all  premises  can  be  satisfied  from  known  formulas.  The 
basic  components  of  the  algorithm — forward  chaining,  backward  chaining,  and 
unification — are  widely  used  methods  in  theorem  proving  and  planning.  We  as¬ 
semble  them  in  a  way  that  takes  advantage  of  the  S-rule/G-rule  distinction,  and 
that  applies  rewrites  transparently  through  a  modified  unification  procedure,  In 
this  section,  we  describe  this  combined  forward/backward  chaining  approach  in 
detail. 

The  skeleton  of  the  TG^  algorithm  is  the  exploration  of  a  directed  graph  which 
has  a  node  for  each  formula  that  will  be  in  the  generated  theory  representation. 
The  roots  of  this  graph  are  the  assumptions,  and  an  edge  from  F  to  G  indicates 
that  the  formula  F  is  used  (perhaps  via  G-rules  and  rewrites)  to  satisfy  a  premise 
of  an  S-rule  which  yields  G.  The  algorithm  enumerates  the  nodes  in  this  graph 
through  a  breadth-first  traversal.  At  each  step  of  the  traversal,  we  consider  all 
possible  applications  of  the  S-rules  using  the  formulas  derived  so  far— -the  visited 
nodes  of  the  graph.  The  new  fringe  consists  of  all  the  new  conclusions  reached 
by  those  S-rule  applications.  When  no  new  conclusions  can  be  reached,  the  ex¬ 
ploration  is  complete  and  the  formulas  already  enumerated  constitute  the  theory 
representation. 

Before  describing  the  algorithm  in  detail,  we  present  a  simple  example  appli¬ 
cation  of  TG^.  The  logic  we  use  has  one  S-rule: 

wearing  (P,  X)  thick  (X) 

warm(P) 


one  G-rule: 


and  one  rewrite: 


G1  : 


thick  (X) 

thick(layered(X ,  Y )) 


W1 :  layered(X,  Y)  =  layered(Y,  X) . 

We  apply  TG^  to  these  initial  assumptions: 

wearing  (alice,  layered(blouse,  sweater)) 
thick  (sweater) 

First,  the  algorithm  tries  to  apply  rule  SI;  unifying  its  primary  premise  with  one 
of  the  known  formulas  gives  this  substitution: 

P  =  alice,  X  =  layered(blouse,  sweater) 
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To  satisfy  the  other  premise,  we  do  backward  chaining  with  the  G-rule,  starting 
with 

thick(layered(blouse,  sweater)) 

This  matches  no  known-valid  formula  directly,  so  we  try  reverse-applying  the 
G-rule  (Gl).  Unifying  the  desired  formula  with  Gl’s  conclusion  (modulo  the 
rewrite,  W 1),  we  get  the  two  substitutions. 


X  =  blouse,  Y  =  sweater 


and 


X  =  sweater,  Y  =  blouse  . 

We  instantiate  Gl’s  premise  with  the  first  substitution,  and  get 


thick  (blouse) 

which  fails  to  match  any  known  formula  or  G-rule  conclusion.  We  then  instantiate 
Gl’s  premise  with  the  second  substitution,  and  reach 


thick  (sweater) 


which  matches  one  of  the  initial  assumptions.  Since  all  Si’s  premises  have  been 
satisfied,  we  proceed  with  the  application,  and  we  add  warm(alice)  to  the  set 
of  known-valid  formulas.  No  further  applications  of  SI  are  possible,  so  TG* 
terminates,  producing  this  theory  representation: 

wearing (alice,  layered(blouse,  sweater)) 

thick  (sweater) 

warm(alice) 


A  pseudocode  sketch  of  the  algorithm  appears  in  Figures  2. 1-2.2.  The 
theory. gen  function  verifies  the  precondition  and  invokes  closure  to  generate  the 
theory,  The  closure  function  performs  the  basic  breadth-first  traversal;  it  builds 
up  a  set  of  formulas  in  T  which  will  eventually  be  the  theory  representation,  while 
keeping  track  of  a  “fringe”  of  newly  added  formulas.  At  each  step,  closure  finds 
all  formulas  derivable  from  (TU  fringe)  with  a  single  S-rule  application  by  calling 
apply. srule  for  each  S-rule.  It  then  takes  the  canonical  forms  of  these  derivable 
formulas,  and  puts  any  new  ones  (not  already  derived)  in  the  new  fringe. 

The  formulas  added  to  T  are  always  canonical  representatives  of  their  equiv¬ 
alence  classes,  under  a  renaming/rewriting  equivalence  relation.  To  be  precise, 
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‘  Generate  the  theory  representation  induced  by  the  given  assumptions,  S-rules, 
G-rules,  and  rewrites,  under  the  pre-order,  <. 

.  The  arguments  to  theory. gen  are  assumed  to  be  in  scope  in  all  other  functions, 
function  theory -gen  (Assumptions .  S^rules,  G-rules,  Rewrites,  = 
if  -'SG. restriction. ok  (S  .rules,  G .rules,  Rewrites ,  <)  then 
raise  BadRules 
else 

return  closure  ( make  .  canonical  [Assumptions ) ,  {}) 

'  Given  a  partially-generated  theory  representation  ( T )  and  some  new  formulas 
.  (fringe),  return  the  theory  representation  of  T  U  fringe. 
function  closure(fringe,T)  — 
if  fringe  =  {}  then 
return  T 
else 

T  <—  T  U  fringe 

fringe'*—  |J  make.canonical(apply.srule(R,T'))\T' 

RG  S-rules 

return  closureifringe' ,  T') 

'  Apply  the  given  S-rule  in  every  possible  way  using  the  formulas  in  known, 

.  with  help  from  the  G-rules  and  rewrites, 
function  apply. srule(R,  known )  = 

return  {apply .subst(c r,  conclusion (R)) 

|  a  6  backward. chain  (premises  (R) ,  known,  {})} 

Figure  2.1:  Sketch  of  the  TG*  algorithm  (part  1  of  2). 

this  relation  equates  formulas  F  and  G  if  there  exists  a  renaming  a  such  that  the 
rewrites  imply  aF  —  aG.  (A  renaming  is  a  substitution  that  only  substitutes 
variables  for  variables.)  By  selecting  these  canonical  representatives,  we  prevent 
some  redundancy  in  the  theory  representation.  The  renaming  equivalence  is  actu¬ 
ally  necessary  to  ensure  termination,  since  variables  can  be  renamed  arbitrarily  by 
the  lower-level  functions.  Requiring  that  formulas  be  canonical  modulo  rewrites, 
while  not  strictly  necessary  for  termination,  does  make  the  algorithm  faster,  and 
perhaps  more  importantly,  makes  the  theory  representation  canonical  in  the  sense 
of  criterion  C4  (from  Section  2.2).  The  canonical  representatives  may  be  chosen 
efficiently  using  a  simple  lexicographical  order. 
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The  apply. srule  function  simply  calls  backward. chain  in  order  to  find  all 
ways  to  satisfy  the  given  S-rule’s  premises.  Note  that,  as  represented  here,  closure 
finds  all  possible  S-rule  applications  and  simply  ignores  the  ones  that  do  not  pro¬ 
duce  new  formulas.  If  the  apply. srule  function  is  told  which  formulas  are  in  the 
fringe,  and  can  pass  this  information  along  to  backward  .chain,  it  can  avoid  many 
of  these  redundant  S-rule  applications,  and  return  only  formulas  whose  deriva¬ 
tions  make  use  of  some  formula  from  the  fringe.  This  optimization,  which  yields 
substantial  speedups,  is  discussed  further  in  Section  6.1.1. 

Figure  2.2  contains  the  three  mutually  recursive  backward-chaining  functions: 
backward  .chain,  backward  .chain. one,  and  reverse,  apply. grule.  The  purpose 
of  backward  .chain  is  to  satisfy  a  set  of  goals  in  all  possible  ways,  with  the  help 
of  G-rules  and  rewrites.  It  calls  choose.goal  to  select  the  first  goal  to  work  on  (g). 
Goals  which  match  some  G-rule  conclusion,  and  thus  may  require  a  deeper  search, 
are  postponed  until  all  other  goals  have  been  met.  (Note  that  these  goals  can  only 
arise  from  G-rule  premises  or  S-rule  side-conditions.)  The  choose.goal  function 
may  apply  further  heuristics  to  help  narrow  the  search  early;  see  Section  6.1.1  for 
some  such  approaches. 

The  backward. chain. one  function  searches  for  a  derivation  of  a  single  for¬ 
mula  (<f>)  with  G-rules  and  rewrites.  It  first  checks  whether  a  canonical  equivalent 
of  (j>  occurs  in  the  visited  set,  and  fails  if  so,  since  those  formulas  are  assumed 
to  be  unprovable.  This  occurrence  corresponds  to  a  derivation  search  which  has 
hit  a  cycle.  If  <f>  is  not  in  this  set,  the  function  renames  variables  occurring  in  <f) 
uniquely,  to  avoid  conflicts  with  variables  in  the  G-rules,  rewrites,  and  known.  It 
then  collects  all  substitutions  that  unify  (j>  (modulo  rewrites)  with  some  formula  in 
known,  and  for  each  G-rule,  calls  reverse. apply  .grule  to  see  whether  that  G-rule 
could  be  used  to  prove  <f.  Each  substitution  that  satisfies  <j)  either  directly  from 
known  or  indirectly  via  G-rules  is  returned,  composed  with  the  variable-renaming 
substitution. 

In  reverse. apply. grule,  we  simply  find  substitutions  under  which  the  conclu¬ 
sion  of  the  given  G-rule’s  conclusion  matches  <p,  and  for  each  of  those  substi¬ 
tutions,  call  backward. chain  recursively  to  search  for  derivations  of  each  of  the 
G-rule’s  (instantiated)  premises. 

The  TG^  algorithm  relies  on  several  low-level  utility  functions,  listed  in  Fig¬ 
ure  2.3.  Most  of  these  are  simple  and  require  no  further  discussion,  but  the  unify 
function  is  somewhat  unusual.  Since  rewrites  can  be  applied  to  any  subformula, 
we  can  most  efficiently  handle  them  by  taking  them  into  account  during  unifi¬ 
cation.  We  augment  a  simple  unification  algorithm  by  trying  rewrites  at  each 
recursive  step  of  the  unification.  In  this  way,  we  avoid  applying  rewrites  until 
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'  Find  the  set  of  substitutions  under  which  the  given  goals  can  be  derived  from 
known  using  G-rules  and  rewrites,  assuming  formulas  in  visited  to  be  unprov- 
L  able. 

function  backward -chain  ( goals ,  known ,  visited)  = 
if  goals  =  {}  then 
return  {[]} 
else 

(j g ,  gs)  <—  choose -goal(goals) 
return  {compose^,  01) 

|  <7i  E  backward -chain  .one{g,  known ,  visited ), 

<j2  E  backward -chain(apply -,subst((Ti,  gs),  known,  visited)} 

'  Find  the  set  of  substitutions  under  which  (j)  can  be  derived  from  known  using 
.  G-rules  and  rewrites,  assuming  formulas  in  visited  to  be  unprovable. 

function  backward -chain -one{(f>,  known ,  visited)  = 

<t>  <—  make -canonical  ((f>) 
if  ^  e  visited  then 
return  {} 
else 

oy  <—  unique -renaming  ((f)) 

<pr  *—  apply subst(ar,(f>) 

regular  substs  <—  U  unify  ((j)r,F) 

Feknown 

grule substs  <—  [J  reverse -apply -grule(R,(j)r,  known, 

Re  G-rules  visited  U  {0}) 

return  {compose(a,ar)  |  a  E  regular  substs  U  grulesubsts } 

=  Find  the  set  of  substitutions  under  which  4>  can  be  derived  from  known  by 
a  proof  using  G-rules  and  rewrites,  and  ending  with  the  given  G-rule  (R), 
.  assuming  formulas  in  visited  to  be  unprovable. 
function  reverse -apply -grule(R,  <f>,  known,  visited)  - 
return  {compose (04 >  03) 

|  <73  €  unify ((f),  conclusion (R)), 

<74  E  backward -chain(applysubst(a3,  premises (R)), 

known,  visited) 


Figure  2.2:  Sketch  of  the  TG^  algorithm,  continued  (part  2  of  2). 
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SG. restriction. ok  (S,  G,  R ,  ■<) 

Check  that  the  S/G  restriction  holds  for 
the  given  rules,  rewrites,  and  pre-order. 

choose. goal{goals) 

Select  a  goal  to  satisfy  first,  and  return 
that  goal  and  the  remaining  goals  as  a 
pair;  prefer  goals  that  match  no  G-rule 
conclusions. 

apply .subst(a,  $) 

Replace  variables  in  <&  (a  formula  or  set 
of  formulas),  according  to  the  substitu¬ 
tion,  a. 

make  .  canonical  (F) 

Return  a  canonical  representative  of  the 
set  of  formulas  equivalent  to  F  modulo 
rewrites  and  variable  renaming  (can  also 
be  applied  to  sets  of  formulas). 

unify  (F,G) 

Return  a  set  containing  each  most- 
general  substitution,  a,  under  which  the 
rewrites  imply  oF  —  oG. 

unique. renaming  (F) 

Return  a  substitution  that  replaces  each 
variable  occurring  in  F  with  a  variable 
that  occurs  in  no  other  formulas. 

compose((Ji,cr2) 

Return  the  composition  of  substitution 
<t i  with  02 . 

Figure  2.3:  Auxiliary  functions  used  by  the  TG*  algorithm. 


and  unless  they  actually  have  some  effect  on  the  unification  process.  Plotkin  de¬ 
scribed  a  similar  technique  for  building  equational  axioms  into  the  unification 
process  [Plo72].  Because  of  the  rewrites,  the  unification  procedure  produces  not 
just  zero  or  one,  but  potentially  many  “most  general  unifiers.” 

The  TG<  algorithm  described  here  can  be  implemented  quite  straightfor¬ 
wardly,  but  various  optimizations  and  specialized  data  structures  can  be  employed 
to  provide  greater  efficiency  if  desired.  In  Section  6.1,  we  discuss  one  implemen¬ 
tation  and  a  set  of  useful  optimizations  it  uses.  The  remainder  of  this  chapter  is 
devoted  to  discussion  of  the  correctness  and  termination  properties  of  the  TG< 
algorithm,  and  its  use  in  a  decision  procedure  for  (.rw- 
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2.3.3  Correctness 


The  TG^  algorithm  is  intended  to  produce  a  theory  representation  in  the  (R,  R') 
form  (see  Section  2.2),  where  the  “preferred”  rules  R!  are  exactly  the  S-rules.  To 
prove  that  it  does  this,  we  need  a  few  lemmas  describing  the  behavior  of  certain 
components  of  the  TG^  algorithm.  These  lemmas  assume  that  the  various  func¬ 
tions  always  terminate;  the  termination  proofs  appear  in  the  next  section. 

All  formulas  and  proofs  referred  to  below  are  assumed  to  be  in  £rw  unless 
explicitly  stated  otherwise.  In  the  correctness  and  termination  proofs,  we  will 
make  use  of  two  restricted  forms  of  proof  within  (rw-  We  write, 

T\~wcf> 

if  there  exists  a  proof  of  (p  from  F  using  only  rewrites  (and  instantiation).  If  there 
exists  a  proof  of  <p  from  F  using  rewrites  and  G-rules,  we  write, 

FI ~GW  0  • 

We  present  the  following  claims  regarding  the  unify  function  without  proof, 
since  it  is  a  standard  building  block  and  we  have  not  described  its  implementation 
in  detail. 


Claim  2.2  (unify  soundness)  If  (pi  and  fa  are  formulas  of  £rw,  and  a  is  a  sub¬ 
stitution  such  that 

a  £  unify  (fa,  fa) , 


then 


{fa}  I ~w  a  fa 


and 


{fa}  a  fa  . 


Claim  2.3  (unify  completeness)  Let  fa  and  fa  be  formulas  of  £ rw  that  share  no 
variables,  and  let  a  be  a  substitution,  such  that 


{fa}  bw  a  fa 


or 


{fa}  bff  ofa  . 


There  exists  a  substitution,  o',  such  that 


o'  £  unify  (fa,  fa) 

and  a  is  an  extension  of  o'.  (That  is,  there  exists  a"  such  that  a  =  a"  o  o'). 
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This  lemma  demonstrates  the  soundness  of  backward  .chain:  that  each  substi¬ 
tution  it  returns  can  be  applied  to  the  given  goals  to  yield  provable  formulas. 

Lemma  2.4  (backward. chain  soundness)  Let  $  and  V  be  sets  of  formulas  of 
H-rw>  l^t  r  be  a  set  of  formulas  of  Irw>  and  let  o  be  a  substitution,  such  that 

a  £  backward  .chain  ($,  T,  V)  . 


Then,  for  every 

T\~ow  a<f> . 

Proof:  This  proof  is  by  induction  on  the  total  number  of  recursive  invocations  of 
backward. chain.  We  assume  that  any  invocation  of  backward. chain  that  causes 
fewer  than  n  recursive  calls  satisfies  the  lemma,  and  show  that  the  result  holds  for 
n  recursive  calls  as  well. 

In  order  for  backward. chain  to  return  a,  it  must  be  the  case  that  either  F  is 
empty  and  o  is  the  identity  (in  which  case  the  result  follows  trivially),  or  a  = 
02  o  oi,  where 

$  =  {g}  U  gs 

o\  £  backward. chain.one(g,  known,  visited) 

02  €  backward. chain(apply.subst(oi,gs),  known,  visited)  . 

Examining  backward. chain. one,  we  see  that  o\  can  arise  in  two  ways:  from 
regular. substs  or  from  grule.substs.  We  will  show  that  in  each  case, 


F  (“gw  o\g  . 


Case  1:  o\  comes  from  regular. substs.  There  must  exist  a  formula  F  £  T, 
and  a  substitution  o[,  such  that 


0\  —  o[  O  Or 

o[  £  unify  (oTg,  F) 

By  Claim  2.2  (unify  soundness),  we  have 

r  (“gw  cri((7r5f)  i 


so 


and  this  case  is  done. 


F  (“gw  °\9 
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Case  2:  04.  comes  from  grulesubsts.  There  must  exist  a  G-rule,  R,  and  a 
substitution  a[,  such  that 

01  —  a\  o  crr 

a[  €  reverse  -apply  -grule(R,  oy  g,  F, . . .) 

(We  ignore  the  visited  argument,  since  it  is  irrelevant  to  soundness.)  Following 
into  reverse -apply -grule ,  we  find  that 

=  <t4  °  era 

03  6  unify  (arg,  conclusion(R)) 

04  €  backward -chain(applysubst(a3, premises(R)),  F, . , .) 

Claim  2.2  (unify  soundness)  implies  that 

{conclusion(R)}  hw  <J3(arg)  . 


By  the  induction  assumption,  for  every  P  in  premises(R), 

F  Kjw  0-4  (cr3P)  . 


We  can  rename  variables  in  these  premise-proofs  using  oy,  then  combine  them 
and  add  an  application  of  the  G-rule,  R,  with  the  substitution  o'x  o  oy,  to  get 

F  How  a[arg . 


This  simplifies  to 


rhow  al9  > 


so  Case  2  is  done, 

We  now  return  to  backward -chain,  armed  with  die  knowledge  that  a%g  has  a 
proof  from  r.  By  adding  instantiation  steps,  we  can  convert  this  proof  to  a  proof 
of  <T2&ig,  so  we  have 

F  how  02  (0i 9) 

We  can  apply  the  induction  assumption  to  the  recursive  backward -chain  invoca¬ 
tion,  yielding 

F  hew  02 (01G) 

for  every  G  e  gs ,  Since  $  «=  {0}  U  gs,  and  a  =  we  have  shown  that  for 

every  </>€$,  there  exists  a  proof  of 


ri-GW  0"^ , 
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using  no  S-rules.  ■ 

Now  we  show  the  dual  of  Lemma  2.4,  the  completeness  of  backward -chain1, 
that  is,  that  it  returns  every  most-general  substitution  under  which  the  goals  are 
provable. 

Lemma  2.5  {backward -chain  completeness)  Let  T  and  V  be  sets  of  formulas, 
let  be  a  set  of  formulas  ({(pi, . . .  ,(pn}),  let  o  be  a  substitution,  and  let  V\ . . .  Vn 
be  proofs  (using  no  S-rules),  such  that  for  1  <  i  <  n, 

Vi 

r  h  gw  cr  <pl 

and  the  proofs,  Vi,  contain  no  rewrites  of  formulas  in  V.  Then,  if  backward  .chain 
terminates,  there  exists  a  substitution,  o',  such  that 

o'  £  backward  .chain  ($,  T,  V) 
and  o  is  an  extension  of  o'. 

Proof:  We  prove  this  lemma  by  induction  on  the  total  number  of  G-rule  applica¬ 
tions  in  Vi . . .  Vn- 

Without  loss  of  generality,  we  assume  that  the  proofs,  V\ . . ,  Vn,  have  no  “shar¬ 
ing.”  That  is,  for  any  proof  line  that  is  used  as  a  premise  more  than  once,  we 
duplicate  the  proof  prefix  ending  with  that  line  to  eliminate  the  sharing.  To  carry 
out  the  induction,  we  now  assume  that  the  lemma  holds  when  Vi--.Vn  contain  a 
total  of  fewer  than  n  G-rule  applications,  and  show  that  it  holds  when  there  are  n 
G-rule  applications. 

In  the  case  where  T  is  empty,  the  lemma  holds  trivially,  so  assume  T  is  non¬ 
empty.  Let  <pi  be  the  first  goal  selected  by  choose.goal.  There  are  two  cases  to 
consider,  depending  on  whether  V,  contains  any  G-rule  applications. 

Case  1:  V%  contains  no  G-rule  applications. 

Looking  at  the  call  to  backward  .chain  .one,  we  can  see  that  the  (p  £  visited 
check  will  not  be  triggered  since  <pi  must  be  in  the  proof  Vi,  and  thus  no  rewrite 
of  it  can  appear  in  V.  Since  or  is  just  a  renaming,  there  exists  some  o'  such  that 

O  —  o'  o  Or  . 


Thus, 


r  I~gw  °  Grtpi 
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and  Claim  2,3  implies  there  exists  some  a"  for  which 

a"  e  1J  unify  (fa,  F) 

Feknown 

and  a'  is  an  extension  of  o".  The  set  returned  by  backward -chain -one  will 
thus  include  a"  o  ar,  of  which  o'  o  aT  (that  is,  er)  is  an  extension.  Therefore, 
backward. chain  will  return  as  one  of  its  results,  «r2  o  (jlt  where  a  is  an  extension 
of  <7i,  and 

02  £  backward  .chain  (apply  subst  (a !,  gs),F,  V)  . 

We  have  thus  reduced  this  case  to  a  case  with  the  same  total  number  of  G-rule 
applications  and  one  fewer  formula  in  <&,  so  without  loss  of  generality  we  can 
assume  the  second  case. 

Case  2:  Vi  contains  at  least  one  G-rule  application. 

The  recursive  call  to  backward. chain  passes  a  (partially  instantiated)  subset 
of  $  (all  but  fa);  since  Vi  contains  some  G-rule  applications,  the  proofs  for  this 
subset  must  contain  fewer  G-rule  applications  than  V\...  Vn,  so  we  can  apply  the 
induction  hypothesis.  This  implies  that,  as  long  as  a  is  an  extension  of  some  o\, 
the  lemma  holds.  It  remains  only  to  demonstrate  this. 

In  backward -chain -one,  again,  the  <p  €  visited  check  will  not  be  triggered  for 
the  same  reason  as  in  Case  1.  As  in  Case  1,  there  exists  some  a'  such  that 

a  =  0'  q  <jr  . 

Let  R  be  the  last  G-rule  applied  in  the  proof,  Vi.  If  we  can  prove  that 
rever se. apply  .grule(R,  fa,  F,  V  U  {</>}) 

returns  some  a"  of  which  a'  is  an  extension,  then  by  the  argument  in  Case  1, 
backward  .chain -one  will  return  a  substitution  of  which  a  is  an  instance,  so  the 
lemma  will  hold. 

Since  a'  is  just  a  variable-renaming  followed  by  a,  we  can  transform  the  proof 
of  afa,  Vu  into  a  proof  of  a' fa,  called  V-,  by  simple  renaming.  From  VI,  we  can 
extract  a  proof  of  each  premise  of  its  last  G-rule  application,  and  also  a  proof  of 
a' fa  from  the  G-rule  conclusion.  By  Claim  2,3,  o'  is  an  extension  of  some  03 
that  will  be  returned  by  unify (ar  fa,  conclusion (R)).  The  proofs  of  R’ s  premises 
will  not  contain  any  rewrites  of  V,  since  these  proofs  come  from  V[,  and  we 
will  further  assume  they  contain  no  rewrites  of  fa.  (If  they  did,  the  application 
of  R  could  be  eliminated  from  Vi,  so  there  is  no  loss  of  generality  from  this 
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assumption.)  Since  we  have  proofs  of  R’s  premises  (instantiated  by  cr7),  which 
have  fewer  total  G-rule  applications  than  the  original  Vi,  and  since  these  proofs 
contain  no  rewrites  of  formulas  in  the  (expanded)  visited  set,  we  can  apply  the 
induction  hypothesis  and  find  that  for  some  cr4  returned  by  the  backward -chain 
call,  o'  is  an  extension  of  <r4  o  er3,  which  will  be  returned  by  reverse -apply -grule. 
This  is  the  final  result  we  required  to  complete  the  proof  of  the  lemma.  ■ 

Now  we  can  prove  the  soundness  and  completeness  of  the  closure  function, 
the  heart  of  the  TG*  algorithm. 

Lemma  2.6  ( closure  soundness)  Let  T  and  r7  be  sets  of  formulas  of  £rw-  For 
any  formula,  F,  where 

F  €  closure  ( T7,  F) , 

there  exists  a  proof,  V,  o/T  U  T7  h  F,  in  which  the  last  rule  application  (if  any)  is 
of  an  S-rule. 

Proof:  The  proof  is  by  induction  on  the  number  of  recursive  calls  to  closure.  If 
there  are  no  such  calls,  T7  (the  fringe)  must  be  empty,  so  T  is  returned,  and  the 
lemma  is  trivially  satisfied.  Otherwise,  closure  is  called  recursively  with  the  for¬ 
mulas  in  fringe  added  to  T  and  fringe1  becomes  the  new  fringe.  If  we  can  show 
that  all  of  the  fringe'  formulas  have  proofs  from  T  of  the  appropriate  form,  then 
we  can  apply  the  induction  assumption  and  the  lemma  is  proved. 

For  every  S-rule,  R,  closure  calls  apply srule(R,  Tur7),  which  will  return  R’s 
conclusion,  instantiated  by  a,  where  a  comes  from  the  backward -chain  result.  By 
Lemma  2.4  (backward -chain  soundness),  for  each  premise,  P,  of  R,  there  exists 
a  proof  of 

rur7baP 

We  can  concatenate  these  proofs,  followed  by  an  application  of  the  S-rule,  R,  to 
yield  a  proof  of  oC  (where  C  is  R’s  conclusion).  Furthermore,  this  proof  has  no 
rule  applications  following  the  application  of  R,  so  the  proof  is  of  the  appropriate 
form.  It  is  therefore  safe  to  add 

apply subst(o,  conclusion(R)) 


to  the  fringe.  ■ 

To  express  the  next  lemma,  we  introduce  a  notion  of  partial  theory  represen¬ 
tations: 
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Definition  2.17  If  for  any  formula,  0,  and  proof  V,  such  that  V  has  only  one 
S-rule  application  and  no  other  rule  applications  following  it,  and  where 

v 

ri-0, 

it  is  also  the  case  that 

(r'ur)i-,^, 

then  we  call  the  ordered  pair,  (r',  F),  a  partial  theory  representation. 

Note  that  if  T  is  a  theory  representation,  then  ({},  T)  is  a  partial  theory  repre¬ 
sentation.  The  closure  function  takes  a  partial  theory  representation  and  produces 
a  theory  representation: 

Lemma  2.7  ( closure  completeness)  Let  T  and  fringe  be  sets  of  formulas  (of 
£rw),  such  that  (fringe ,  T)  is  a  partial  theory  representation.  For  any  formula, 
(f),  and  proof  V,  whose  last  rule  application  is  an  S-rule  application,  where 

v 

(T  U  fringe)  b  0  , 

there  exists  some  0',  where  (assuming  closure  terminates) 

(jf  £  closure(fringe,T)  , 

such  that 

0'U0. 

Proof:  The  proof  is  by  induction  on  the  number  of  recursive  calls  to  closure,  which 
is  guaranteed  to  be  finite  since  we  assume  closure  terminates. 

If  there  are  no  recursive  calls  to  closure,  then  fringe  is  empty,  and  closure 
returns  just  T,  which  by  Definition  2.17  must  satisfy 

T  b  w  0  , 

so  this  case  is  done. 

If  fringe  is  non-empty,  then  the  function  returns  the  result  of 

closure(fringe' ,T')  . 


Since 


T'  D  (T  U  fringe)  , 
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the  induction  hypothesis  will  yield  the  desired  result  if  we  can  prove  that 

(fringe',  T ') 


is  a  partial  theory  representation. 

Let  </>*  be  a  formula  as  given  in  Definition  2.17,  where 

-p* 

T'  b  <p  , 

and  V*  has  exactly  one  S-rule  application,  which  is  its  last  rule  application.  Let  R 
be  the  last  S-rule  applied  in  V*,  let  C  be  R’s  conclusion,  and  let  a  be  the  substi¬ 
tution  under  which  R  was  applied.  From  Lemma  2.5  (backward. chain  complete¬ 
ness),  it  follows  that  a  is  an  extension  of  some  substitution  returned  by 

backward .chain(premises(R),T',  {})  , 


and  thus 


apply  .srule(R,  T') 


will  return  some  formula  of  which  aC  is  an  instance.  Since  make  .canonical  only 
transforms  one  formula  into  another  that  is  equivalent  modulo  rewrites,  we  get 


make,  canonical  (apply. srule(R,T'))  bw  oC 


and  finally,  this  implies  that 


fringe'  U  T'  bw  aC  .  (2.4) 

Now,  returning  to  the  proof,  V*,  since  no  more  rules  are  applied  after  R,  it  follows 
that 

ffC*  b  yf  (j)  . 

This,  combined  with  (2.4),  gives  the  result  we  need: 

fringe'  U  T’  bw  (f> , 


This  completes  the  induction.  ■ 

We  can  now  prove  the  claim  made  at  the  beginning  of  this  section,  which 
corresponds  to  the  following  theorem: 
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Theorem  2.8  (TG^  Correctness)  If  V  is  a  set  of  mostly- ground  formulas  of  Irw> 
and  S -rules,  G -rules,  Rewrites,  and  <  meet  the  TG^  algorithm  preconditions 
given  in  Definition  2.16,  then 

theory. gen  (T,  S -rules,  G  .rules,  Rewrites ,  <) 

returns  an  (R,  R')  representation  of  the  theory  induced  by  F,  where  R!  is  the  set 
ofS-rules,  and  the  equivalence  used  is  equivalence  modulo  rewrites  and  variable 
renaming. 

Proof:  First  we  prove  that  every  formula  returned  by  theory  .gen  is  in  the  (R,  R1) 
representation.  Let  F  be  a  formula  returned  by  theory  .gen.  It  must  be  the  case 
that 

F  E  closure ( make . canonical (r) ,  {})  , 
and  so  by  Lemma  2.6  ( closure  soundness),  there  exists  a  proof,  V,  such  that 

v 

make.canonical{T )  h  F  , 

and  where  the  last  rule  application  in  V  is  of  an  S-rule.  Since  make  .canonical 
only  transforms  by  rewrites,  we  know  that 

V  V 

make  .canonical  (T)  h  F  ==>-  T  F 

and  furthermore,  that  since  the  last  rule  applied  in  V  is  an  S-rule,  the  same  is  true 
of  V .  Lastly,  since  every  formula  returned  by  closure  has  been  canonicalized,  no 
two  formulas  returned  by  theory. gen  are  equivalent  modulo  rewrites  and  variable 
renamings.  Therefore,  every  formula  returned  by  theory. gen  is  in  the  (R,  RI) 
representation. 

It  remains  to  prove  that  any  formula  in  the  (R,  R!)  representation  is  returned 
by  theory  .gen.  Let  F  be  a  formula  and  V  a  proof  whose  last  rule  applied  is  an 
S-rule,  such  that 

v 

r  h  f  . 

By  the  same  argument  made  above,  it  follows  that 

V 

make  .canonical  (V)  h  F  , 

where  V  has  the  same  property.  By  Lemma  2.7  ( closure  completeness),  there 
exists  some  F', 

<f>'  £  closure(make.canonical( F),  {})  , 
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such  that 


F'KF. 


Therefore,  F  is  equivalent  (modulo  rewrites  and  variable  renaming)  to  some  for¬ 
mula  in  the  set  returned  by  theory. gen.  This  completes  the  correctness  proof  for 
the  TG^  algorithm.  ■ 


2.3.4  Termination 

The  completeness  proofs  in  Section  2.3.3  assumed  that  the  functions  making  up 
the  TG^  algorithm  always  terminated.  In  this  section,  we  show  how  the  TG* 
preconditions  ensure  this.  The  proofs  below  assume  the  existence  of  a  fixed  set 
of  S-rules,  G-rules,  and  rewrites,  and  a  pre-order,  •<,  all  of  which  satisfy  the  TG* 
preconditions  in  Definition  2.16. 

Roughly  speaking,  the  proof  goes  as  follows.  The  backward. chain  function 
first  satisfies  the  primary  premises,  and  then  applies  G-rules  in  reverse  to  satisfy 
the  partially  instantiated  side-conditions.  Since  the  G-rules  ‘’grow”  when  applied 
in  the  forward  direction,  they  “shrink”  when  applied  in  reverse  (if  the  goal  formula 
is  sufficiently  ground),  so  this  backward  chaining  must  terminate.  The  closure 
function  finds  each  way  of  applying  the  S-rules  with  help  from  backward. chain, 
and  repeats  until  it  reaches  a  fixed  point.  Since  the  S-rules  “shrink,”  they  can  never 
produce  a  formula  larger  than  all  the  initial  assumptions,  and  so  this  process  will 
halt  as  well. 

A  more  formal  proof  follows. 

Definition  2.18  A  formula,  F,  is  size-bounded  by  a  finite  set  of  formulas,  T,  when, 
for  any  substitution,  a,  there  exists  G  €  T  such  that 

aF  •<  G  . 

Note  that  if  F  is  mostly-ground  then  F  is  size-bounded  by  {F}. 

Lemma  2.9  If  fa  is  size-bounded  by  T,  and  fa  ^  fa,  then  fa  is  size-bounded  by 

r. 

Proof:  Since  fa  ■<  fa,  we  can  use  pre-order  condition  P2  (^  preserved  under 
substitution)  to  show  that,  for  any  o, 


a  fa  ^  ofa  . 


2.3.  THE  THEORY  GENERATION  ALGORITHM,  TG* 


39 


Since  4>  1  is  size-bounded  by  F,  there  exists  some  G  €  T  such  that 

a(j>i  •<  G . 

Applying  the  transitive  property  of  pre-orders,  we  get 


0(/> 2  ■<  G  , 


so  (f> 2  is  size-bounded  by  F.  ■ 

Lemma  2.10  If  the  formula,  F,  is  size-bounded  by  T,  then  for  any  formula,  F', 
such  that 

{F}  h WF' , 

F'  is  also  size-bounded  by  T. 

Proof:  We  show  that  size-boundedness  is  preserved  by  instantiation  and  by  rewrit¬ 
ing,  the  only  transformations  possible  in  the  proof  of 

m  hw  f'  . 

Let  a  be  some  substitution.  Since  F  is  size-bounded  by  T,  there  exists  some 
GeT  such  that  for  any  substitution,  o', 

o'oF  <  G , 

so  oF  is  size-bounded  by  T.  Let  S  =  T  be  a  rewrite,  and  let  F'  be  the  result  of 
applying  that  rewrite  to  F.  Rewrites  are  required  to  be  size-preserving,  so  -S'  ^  T 
and  T  r<  S.  By  pre-order  condition  PI,  this  implies  F'  ■<  F,  and  we  can  apply 
Lemma  2.9  to  see  that  F'  is  size-bounded  by  T.  ■ 

Lemma  2.11  IfF  is  size-bounded  by  F,  then  make _  canonical  (F)  is  size-bounded 
by  F. 

Proof:  Since  make -canonical  only  transforms  by  rewrites  and  variable  renaming, 
it  follows  directly  from  Lemma  2.10  that  make -canonical  (F)  is  size-bounded  by 
F  if  F  is,  ■ 

Lemma  2,12  For  any  finite  set  of  formulas,  F,  there  are  finitely  many  formulas 
that  are  both  size-bounded  by  T  and  canonical  with  respect  to  variable-renaming. 
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Proof:  By  Definition  2.18,  any  formula,  4>,  that  is  size-bounded  by  T  must  satisfy 
4>  G  for  some  G  £  T.  By  pre-order  condition  P3,  since  T  is  finite,  there  are 
finitely  many  such  formulas,  modulo  variable  renaming. 

Lemma  2.13  Iff  is  size-bounded  by  the  set  of  formulas,  P,  and  R  is  a  G-rule, 
then 

reverse  .apply. grule(R,  f,  T,  V) 

will  always  pass  a  set  of  formulas,  to  backward  .chain,  where  all  formulas  in 
$  are  size-bounded  by  P.  (T  need  have  no  relation  to  P;  in  particular  P  may 
contain  larger  formulas  than  P) 

Proof:  Let  C  be  R' s  conclusion.  For  any  o3,  such  that 

o3  £  unify  (4),  C) , 

Claim  2.2  ( unify  soundness)  implies  that 


{0}  hw  a3C . 

Since  f  is  size-bounded  by  T',  it  follows  that  o3C  is  also  size-bounded  by  T'. 
From  the  G-rule  definition,  for  all  premises,  P,  of  R, 

PIC, 


and  so 

a3 P  X  o3C  . 

By  Lemma  2.9,  o3P  must  be  size-bounded  by  Iv.  The  call  to  backward  .chain 
sends  only  formulas  of  this  form.  ■ 

Lemma  2.14  If  all  formulas  in  T  are  size-bounded  by  P,  and  <f)  matches  no  G- 
rule  conclusion,  then  for  every  o  such  that 

a  €  backward. chain. one{(f),T ,V)  , 

of  is  size-bounded  by  P. 

Proof:  Since  <j>  matches  no  G-rule  conclusion,  neither  will  the  renamed  version, 
4>r,  and  so  grule.substs  will  be  empty.  By  Claim  2.2  ( unify  soundness),  for  every 
o'  such  that 


a'  £  unify  (<pr,  F) 
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where  F  £  F,  we  know  that 

{F}  hw  <j’<fir  . 

Therefore,  by  Lemma  2.10,  since  F  is  size-bounded  by  F',  so  is  <j'4>r.  Finally,  the 
substitutions  returned  by  backward  .chain. one  are  o'  o  <jr,  and 

<J  4>r  —  &  Grfy  > 

so  (a1  o  ar)(f>  is  size-bounded  by  T',  ■ 

Lemma  2.15  IfT  is  size-bounded  by  F',  and  there  exists  some  0  £  $  such  that  0 
matches  no  G-rule  conclusion,  then  for  every  o  such  that 

o  £  backward .chain($,  T,  V)  , 

<r 0  is  size-bounded  by  T'. 


Proof:  Each  recursive  call  to  backward-chain  applies  another  substitution  to  the 
remaining  goals,  and  substitution  cannot  cause  a  formula  to  match  a  G-rule  con¬ 
clusion  if  it  did  not  already,  and  it  also  preserves  size-boundedness.  Therefore,  in 
some  call  to  backward  .chain,  the  chosen  goal,  g,  will  match  no  G-rule  conclu¬ 
sions  and  will  be  size-bounded  by  T'.  By  Lemma  2,14,  every  ox  substitution  such 
that 


<Ti  £  backward. chain  .one  (g,  T,  V) 


will  give  oig  size-bounded  by  T'.  The  substitutions  returned  by  the  original 
backward  .chain  invocation  are  extensions  of  these  <ti  substitutions,  so  <70  will 
be  size-bounded  by  F',  ■ 


Lemma  2.16  If  4>  is  size-bounded  by  F',  then  backward. chain. one(<p,  T,  V)  will 
always  pass  the  formula  0r  to  reverse  .apply  ^grule,  where  <t>T  is  also  size-bounded 
by  r.  • 


Proof:  This  follows  directly  from  the  definition  of  size-bounded,  since  0r  is  the 
result  of  a  substitution  applied  to  0.  ■ 


Lemma  2.17  If  T  is  size-bounded  by  T' ,  and  $  is  the  set  of  premises  of  some 
S-rule,  then  backward .chain($,  T,  V )  will  terminate. 


42 


CHAPTER  2.  THEORY  GENERATION 


Proof:  Since  choose-goal  always  selects  goals  that  match  no  G-rule  conclusions 
first,  backward. chain  will  satisfy  all  the  primary  premises  in  $  before  examin¬ 
ing  side-conditions.  For  each  primary  premise,  backward. chain. one  will  clearly 
terminate  since  reverse,  apply. grule  will  not  call  backward  .chain. 

Let  ap  be  the  accumulated  substitution  once  the  primary  premises  have  been 
satisfied.  Since  oC  is  size-bounded  by  T7,  and  each  side-condition,  P,  satisfies 

P<C% 

it  follows  from  Lemma  2.9  that  for  each  side-condition,  aP  is  size-bounded 
by  F.  A  simple  induction  shows  that  the  recursive  call  to  backward. chain 
in  backward. chain  itself  will  preserve  this  property,  and  reduces  the  num¬ 
ber  of  goals  by  one,  so  the  only  possibly  non-terminating  call  is  the  one  to 

backward. chain  .one. 

The  call  to  backward. chain. one  passes  a  formula,  0,  that  is  size-bounded 
by  r'.  By  Lemmas  2.13  and  2.16,  any  recursive  call  made  to  backward. chain 
in  reverse  .apply. grule  will  use  goals  also  size-bounded  by  T7.  Since 
backward  .chain. one  adds  the  canonical  form  of  0  to  the  visited  set,  and  ter¬ 
minates  if  0  is  already  in  that  set,  the  recursive  nesting  depth  is  bounded  by  the 
number  of  such  formulas  0  that  are  distinct  modulo  renaming.  Since  each  such  0 
is  size-bounded  by  T,  pre-order  condition  P3  implies  that  there  are  a  finite  num¬ 
ber  of  possible  0’s.  Therefore,  this  recursion  must  halt,  so  backward. chain  will 
terminate.  ■ 

Lemma  2.18  If  the  formulas  in  T  are  size-bounded  by  T7,  and  R  is  an  S-rule,  then 
the  formulas  returned  by  apply. srule(R,  T)  are  size-bounded  by  T7. 

Proof:  Let  C  be  the  conclusion  of  the  S-rule,  R,  and  let  P  be  a  primary  premise 
of  R  that  satisfies 

C  <P  ■ 

By  the  S-rule  definition,  some  such  P  must  exist,  and  by  the  S/G  restriction, 
P  must  match  no  G-rule  conclusions.  Lemma  2.15  thus  implies  that  for  every 
substitution,  a,  such  that 

a  €  backward  .chain  (premises(R),  T,  {})  , 

oP  is  size-bounded  by  F7.  By  the  S-rule  definition, 

C^P 


) 
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so  by  pre-order  condition  P2, 

aC  ■<  aP , 

and  since  aP  is  size-bounded  by  Tf,  Lemma  2.9  implies  that  aC  is  size-bounded 
by  T.  ■ 

Lemma  2.19  If  formulas  in  T  are  size-bounded  by  T',  and  R  is  an  S-rule,  then 
apply  srule(R,  T)  will  terminate. 

Proof:  The  call  to  backward -chain  passes  the  premises  of  R  and  the  set  T,  so  the 
antecedent  of  Lemma  2. 17  is  satisfied,  and  backward -chain  (and  thus  apply  srule) 
will  terminate.  ■ 

Lemma  2.20  In  closure,  if  the  formulas  in  fringe  and  T  are  size-bounded  by  T, 
then  formulas  in  fringe'  and  T'  are  also  size-bounded  by  T. 

Proof:  First,  T'  is  clearly  size-bounded  by  T  since  V  is  just  fringe  (J  T.  By 
Lemma  2.1 1  and  Lemma  2.18,  for  each  S-rule,  R, 

make -canonical  ( apply -srule  (R,  T')) 

is  size-bounded  by  F,  and  so  fringe'  is  also  size-bounded  by  T.  ■ 

Lemma  2.21  If  formulas  in  fringe  and  T  are  size-bounded  by  some  finite 
set,  F,  and  canonical  with  respect  to  rewrites  and  variable  renaming,  then 
closure(fringe,T)  will  terminate. 

Proof:  In  each  recursive  call,  the  set  fringe  U  T  must  grow  monotonically,  until 
fringe  is  empty  and  closure  terminates.  By  Lemma  2.19,  apply srule(R,  T')  must 
terminate 

By  Lemma  2.20,  and  the  definition  of  make -canonical,  these  invariants  are 
preserved: 

»  Formulas  in  fringe  LIT  are  size-bounded  by  T. 

•  Formulas  in  fringe  U  T  are  canonical  with  respect  to  rewrites 

Therefore,  by  Lemma  2.12,  there  are  finitely  many  formulas  that  can  ever  be  added 
to  fringe  (J  T,  and  so  the  recursion  must  terminate.  ■ 

We  can  now  prove  the  termination  theorem  for  the  TG*  algorithm: 

Theorem  2.22  If  the  TG^  preconditions  hold,  then  theory -gen  will  terminate. 

Proof;  Assumptions  are  mostly-ground,  so  they  are  size-bounded  by  themselves. 
By  Lemma  2.11,  the  formulas  passed  to  closure  are  size-bounded  by  T,  and  they 
are  also  canonical  with  respect  to  rewrites  and  variable  renaming,  so  Lemma  2.21 
implies  that  closure,  and  thus  theory  .gen,  will  terminate.  ■ 
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2.4  The  Decision  Problem 

One  of  the  goals  (Section  2.2)  for  the  theory  representation  was  that  it  would  en¬ 
able  an  efficient  decision  procedure  for  the  full  theory.  In  other  words,  we  should 
be  able  to  make  use  of  the  theory  representation  generated  from  T  to  answer  the 
question, 

r  h  0  (2.5) 

when  T  is  a  set  of  mostly-ground  formulas,  and  Irw  satisfies  the  TGf  precondi¬ 
tions. 

In  this  section,  we  first  discuss  the  decidability  of  the  £rw  logics  in  general, 
and  then  give  a  simple  and  fast  decision  procedure  that  makes  use  of  the  generated 
theory  representation. 

2.4.1  Decidability  of  £rw 

Since  logical  implication  for  full  first-order  logic  is  undecidable,  we  might  well 

ask  whether  (2.5)  can  be  decided  in  iRW. 

? 

The  T  <j)  question  is  equivalent  to  deciding  the  logical  validity  of  this  (gen¬ 
eral  first-order)  formula: 


{Ai  A  ...  A  An)  A  (Ri  A  ...  A  Rn)  A  {W\  A  ...  A  Rn)  =4-  0  (2.6) 

where  T  =  {Ai, An},  and  the  Ri  and  are  the  rules  and  rewrites  of  £rw- 
Each  of  these  formulas  {Ai,  Ri,  Wu  0)  is  a  well-formed  formula  of  C=,  so  re¬ 
calling  the  restriction  on  formulas  in  Cr,  we  know  that  they  each  have  the  form 
VXi, . . . ,  Xm.F,  where  F  contains  no  quantifiers.  We  can  pull  the  quantifiers  in 
(2.6)  outward,  renaming  bound  variables  to  avoid  clashes,  to  produce  this  equiva¬ 
lent  formula: 

(VX.(Fa  A  F2  A  ...  A  Fn))  =>  (VY.G)  (2.7) 

This  formula,  in  turn,  can  be  rewritten  as 


Vy.3X((Fx  A  F2  A  ...  A  Fn)  =$>  G) 

Since  the  Fi  and  G  are  quantifier-free,  this  formula  has  the  form 

VY1....VYn3Xl....BXm.S 

Validity  is  known  to  be  decidable  for  first-order  formulas  in  this  form  [DG79], 
and  thus  the  logical  implication  question  stated  above  is  decidable. 
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2.4.2  Decision  Procedure 

Given  a  generated  theory  representation  for  T,  and  a  mostly-ground  formula  <fr, 

? 

the  procedure  for  deciding  F  h  <f>  is  simply  this: 

function  derivable ((f),  theory. rep)  = 

return  backward. chain({4>},  theory. rep,  {})  ^  {} 

The  correctness  and  termination  of  this  decision  procedure  follow  directly  from 
the  correctness  and  termination  of  the  backward. chain  function  (Lemmas  2.4, 
2.5,  and  2.17).  It  is  efficient  in  practice. 

2.5  Theory  Generation:  Summary 

We  have  defined  the  general  theory  generation  approach:  build  a  representation  of 
the  full  theory  induced  by  some  set  of  assumptions,  and  use  that  representation  to 
directly  and  indirectly  explore  the  consequences  of  those  assumptions.  We  then 
considered  theory  generation  in  the  context  of  a  particular  fragment  of  first-order 
logic,  £rw-  We  specified  the  (R,  R')  class  of  theory  representations,  based  on 
selecting  a  set  (/?')  of  “preferred”  rules,  to  be  applied  aggressively.  For  assump¬ 
tions,  rules,  and  rewrites  satisfying  the  specified  preconditions,  we  described  a 
theory  generation  algorithm  that  produces  a  representation  in  this  class,  Finally, 
we  presented  a  decision  procedure  for  mostly-ground  formulas  in  Irw  which 
makes  use  of  the  theory  representation.  The  decision  procedure  (derivable)  satis¬ 
fies  the  following  property,  where  preconds  refers  to  the  TG«  preconditions  given 
in  Definition  2.16: 

preconds  (T°,  S. rules,  G  .rules,  Rewrites,  X) 

=>■  ((f)  E  T*  4=4-  derivable  ((f),  theory  .gen  (T0))) 

That  is,  for  a  logic  and  initial  set  of  formulas,  T°,  that  satisfy  the  TG^  precon¬ 
ditions,  a  formula,  <f>,  is  in  the  theory  induced  by  T°  if  and  only  if  the  decision 
procedure  returns  true,  given  (f>  and  the  results  of  the  TGr  algorithm. 

In  the  following  chapters,  we  apply  theory  generation  in  the  domain  of  cryp¬ 
tographic  protocol  verification,  and  see  what  practical  benefits  it  offers, 
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Chapter  3 

Theory  Generation  for  Belief  Logics 


“little  logics”  have  been  used  successfully  to  describe,  analyze,  and  find  flaws  in 
cryptographic  protocols.  The  BAN  logic  is  the  best-known  member  of  a  family 
of  logics  that  seem  to  capture  some  important  features  of  these  protocols  while 
maintaining  a  manageable  level  of  abstraction.  There  has  been  little  in  the  way 
of  tools  for  automated  reasoning  with  these  logics,  however.  Some  of  the  BAN 
analyses  were  mechanically  verified,  and  the  designers  of  AUTLOG  produced  a 
prover  for  their  logic,  but  prominent  automated  tools,  such  as  the  NRL  Protocol 
Analyzer  and  Paulson’s  Isabelle  work,  have  used  very  different  approaches.  The 
lack  of  emphasis  on  automation  for  these  logics  results  in  part  from  their  apparent 
simplicity;  it  can  be  argued  that  proofs  are  easily  carried  out  by  hand.  Indeed,  the 
proofs  rarely  require  significant  ingenuity  once  appropriate  premises  have  been  es¬ 
tablished,  but  manual  proofs  even  in  published  work  often  miss  significant  details 
and  assume  preconditions  or  rules  of  inference  that  are  not  made  explicit;  auto¬ 
mated  verification  keeps  us  honest.  Furthermore,  with  fast,  automated  reasoning 
we  can  perform  some  analyses  that  would  otherwise  be  impractical  or  cumber¬ 
some,  such  as  enumerating  beliefs  held  as  the  protocol  progresses. 

The  development  of  theory  generation  was  partially  motivated  by  the  need  for 
automated  reasoning  with  this  family  of  logics.  Using  theory  generation,  and  the 
TGf  algorithm  in  particular,  we  can  do  automated  reasoning  for  all  these  logics 
with  a  single,  simple  tool. 

In  this  chapter,  we  examine  three  belief  logics  in  the  BAN  family:  the  BAN 
logic  of  authentication,  AUTLOG,  and  Kailar’s  logic  of  accountability,  and  we 
show  how  theory  generation  can  be  applied  to  each  of  them.  For  each  logic, 
we  present  its  representation  as  a  set  of  functions  and  predicates,  its  axioms  (the 
“rules”  fed  to  the  TG^  algorithm),  and  an  appropriate  pre-order  (^), 
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3.1  BAN 

As  the  progenitor  of  this  family,  the  BAN  logic  of  authentication  is  a  natural  case 
to  consider.  This  logic  is  normally  applied  to  authentication  protocols.  It  al¬ 
lows  certain  notions  of  belief  and  trust  to  be  expressed  in  a  simple  manner,  and  it 
provides  rules  for  interpreting  encrypted  messages  exchanged  among  the  parties 
(principals)  involved  in  a  protocol.  In  Section  3.1.1  we  enumerate  the  fundamen¬ 
tal  concepts  expressible  in  the  BAN  logic:  belief,  trust,  message  freshness,  and 
message  receipt  and  transmission;  Section  3.1.2  contains  the  rules  of  inference; 
Sections  3. 1.3-3. 1.5  give  examples  of  their  application. 


3.1.1  Components  of  the  Logic 

In  encoding  the  BAN  logic  and  its  accompanying  sample  protocols,  we  must  make 
several  adjustments  and  additions  to  the  logic  as  originally  presented  [BAN90],  to 
account  for  rules,  assumptions,  and  relationships  that  are  missing  or  implicit. 

Figure  3.1  shows  the  functions  used  in  the  encoding,  and  their  intuitive  mean¬ 
ings.  The  first  twelve  correspond  directly  to  constructs  in  the  original  logic,  and 
have  clear  interpretations.  The  last  two  are  new:  inv  makes  explicit  the  relation¬ 
ship  implied  between  the  keys  in  a  key  pair  ( K ,  K~l)  under  public-key  (asym¬ 
metric)  cryptography,  and  distinct  expresses  that  two  principals  are  not  the  same. 

As  a  technical  convenience,  we  always  assume  that  for  every  function  (e.g., 
believes ),  there  is  a  corresponding  predicate  by  the  same  name  and  with  the  same 
arity,  which  is  used  when  the  operator  occurs  at  the  outermost  level.  For  instance, 
in  the  BAN  formula 

A  believes  B  said  A  believes  A  B 

the  first  believes  is  represented  by  the  believes  predicate,  while  the  second  is  rep¬ 
resented  by  the  believes  function.  The  function  and  predicate  have  the  same  name 
merely  for  convenience;  there  is  formally  no  special  relationship  between  the  two. 
The  duplication  is  required  since  we  have  chosen  a  first-order  logic  setting;  if  in¬ 
stead  we  used  modal  logic,  we  could  replace  the  function/predicate  pair  with  a 
single  modal  operator.  This  is  a  technical  distinction  with  no  significant  implica¬ 
tions  in  practice. 

We  provide  a  finite  but  unspecified  set  of  uninterpreted  0-ary  functions  (con¬ 
stants),  which  can  be  used  to  represent  principals,  keys,  timestamps,  and  so  forth 
in  a  specific  protocol  description. 
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Function 

BAN  notation 

Meaning 

believes  ( P,X ) 

P  believes  X 

P  believes  statement  X 

sees(P,X) 

P sees  X 

P  sees  message  X 

said(P,  X ) 

P  said  X 

P  said  message  X 

controls  (P,  X) 

P  controls  X 

if  P  claims  X,  X  can  be 
believed 

fresh(X) 

fresh(X) 

X  has  not  been  uttered 
before  this  protocol  run 

shared  Jcey(K,  P,  Q) 

P&Q 

K  is  a  symmetric  key 
shared  by  P  and  Q 

public-key(K,  P) 

&P 

K  is  P’s  public  key 

secret  (Y,  P,  Q) 

P^Q 

Y  is  a  secret  shared  by  P 
and  Q 

encrypt  (X,  K,  P) 

{X}k  from  P 

message  X,  encrypted 
under  key  K  by  P 

combine  (X ,  Y) 

(X)y 

message  X  combined 
with  secret  Y 

comma(X,Y) 

X,Y 

concatenation 

A,B,S,T,... 

a,b,s,t,  . . . 

0-ary  functions  (con¬ 
stants) 

inv(Ki,  Kf) 

Ki  and  K2  are  a  pub¬ 
lic/private  key  pair 

distinct  (P,  Q) 

principals  P  and  Q  are 
not  the  same 

Figure  3.1:  BAN  functions 

In  order  to  apply  the  TG^  algorithm  to  reason  with  the  BAN  logic,  we  must 
define  a  pre-order,  ^ ban ,  on  terms  and  formulas.  Before  we  can  do  that,  however, 
we  must  place  some  constraints  on  the  terms  and  formulas  in  the  BAN  encoding. 
Specifically,  we  require  that  function  and  predicate  arguments  corresponding  to 
principal  names  must  be  simple  variables  or  constants. 

Definition  3.1  The  atomic  arguments  of  BAN  functions  and  predicates  are  those 
in  positions  indicated  by  P  and  Q  in  Figure  3.1. 

Definition  3.2  The  terms  and  formulas  of  BAN  are  all  those  terms  and  formulas 
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in  Irw  built  from  the  functions  and  predicates  in  Figure  3.1,  and  in  which  all 
atomic  arguments  are  either  variables  or  0-ary  functions. 

With  this  constraint,  we  can  still  express  all  BAN  formulas.  This  constraint,  com¬ 
bined  with  the  following  pre-order,  enables  us  to  apply  the  TG^  algorithm. 

Definition  3.3  The  pre-order  <ban  is  defined  over  BAN  terms  and  formulas  as 
follows : 

F  ;< ban  G  =  (nsyms(F)  <  nsyms(G )) 

A  (Vv.occ(v,F)  <  occ(v,G )) 

nsyms(F)  =  the  number  of  functions,  predicates,  and  variables 
in  F,  excluding  those  in  atomic  arguments 
occ(v,  F)  =  the  number  of  occurrences  of  variable  v  in  F,  ex¬ 
cluding  occurrences  in  atomic  arguments 

For  this  relation  to  be  acceptable  for  use  with  the  TG^  algorithm,  it  must  be  a 
pre-order  and  also  satisfy  conditions  P1-P3  (Section  2.3). 

Claim  3.1  The  relation  ^ban  is  a  pre-order  and  satisfies  conditions  P1-P3. 

Proof:  The  relation  is  clearly  reflexive  and  transitive,  so  it  is  a  pre-order. 

When  we  substitute  a  term,  T,  for  all  occurrences  of  a  variable,  X,  in  F,  we 
can  compute  nsyms  and  occ  exactly  for  the  new  formula  as  follows: 

7isyms([T\X]F)  =  nsyms(F)  +  occ(X,  F)  ■  nsyms(T)  (3.1) 

occ (v  \T\X]F)  =  l  0CC(X’ '  0CC(V>T)  if  v  =  X 

’  '  ^  |  occ(v,  F)  +  occ(X,  F)  •  occ(v,  T)  otherwise  '  ' 

It  then  follows  that,  for  any  terms  Ti  and  T2, 

nsyms(Ti)  <  nsyms(T2 )  =r-  (nsyms ([Ti\X]F)  <  nsyms ([T2\X]F)) 


and 


occ(v,Ti)  <  occ(v,T2)  (occ(v,  [T^XjF)  <  occ( v,  [T2\X]F)) 
so  condition  PI  is  satisfied  by  -<ban • 

(Ti  Iban  T2)  =»  ([Tx\X]F  ± BAN  [T2\X]F) 
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From  (3,1)  we  can  further  derive  that  for  any  formulas,  F  and  G,  and  any  term,  T, 

((nsyms(F)  <  nsyms(G ))  A  ( occ(X,F )  <  occ(X,G ))) 

=»  {nsyms{[T\X}F)  <  nsyms([T\X]G)) 

and  from  (3.2), 

(( occ(v ,  F)  <  occ(v,  G))  A  ( occ(X ,  F)  <  occ(X,  G))) 

■=*  ( occ(v ,  [T\X]F)  <  occ(v ,  [T\X]G)) 

so  condition  P2  is  satisfied  by  <ban'- 

(F  dBAN  G)  =>  ({T\X]F  ±3AN  [T\X]G) 

Finally,  we  must  show  that  for  any  G,  the  set  {F  \  F  -<ban  G}  is  finite  modulo 
variable  renaming  (P3).  The  non-atomic  arguments  in  each  such  F  must  contain 
only  variables  appearing  in  G  (since  Vv.occ(v,  F)  <  occ(v,  G)),  and  there  are 
finitely  many  functions  and  predicates  that  can  be  used  to  construct  F,  each  having 
a  fixed  arity.  The  atomic  arguments  in  F  must  each  be  either  a  single  variable  or 
a  member  of  the  finite  collection  of  constants.  The  single  variables  are  either  one 
of  the  finite  set  of  variables  in  G,  or  do  not  appear  outside  atomic  arguments  and 
can  thus  be  canonically  renamed.  Therefore  both  the  length  of  F  and  the  alphabet 
it  is  built  from  are  bounded,  so  the  set  of  all  such  Fs  is  finite.  ■ 


3.1.2  Rules  of  Inference 


The  BAN  logic  contains  eleven  basic  rules  of  inference,  each  of  which  can  be 
expressed  as  an  £rw  rule,  written  in  the  form 


Pl,p2, 

C 


Each  of  these  rules  is  either  an  S-rule  or  a  G-rule  under  the  pre-order  ~<ban,  and 
each  preserves  the  atomic-arguments  constraint  on  BAN  formulas. 

There  are  three  message-meaning  rules  that  allow  one  principal  to  deduce  that 
a  given  message  was  once  uttered  by  some  other  principal: 


BAN!  : 


believes  (P,  shared -key  (K,  Q,  P)) 
sees(P,  encrypt (X,  K,  R)) 
distinct  (P,  R) 

believes  (P,  said(Q,  X)) 
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BAN2  : 


believes  (P,  public -key  (Ki,Q)) 
sees(P ,  encrypt (X,  K2,  R)) 
inv(K1,K2) 
believes(P ,  said(Q,  X )) 


believes  ( P ,  secret (Y,  Q,P )) 

BAN3  sees(P,  combine (X,  Y)) 
believes (P,  said(Q,X)) 

In  each  of  these  rules,  the  conclusion  precedes  the  second  premise  in  -<ban .  so 
they  are  valid  S-rules.  Like  the  other  rules  below,  they  also  preserve  the  constraint 
on  BAN  formulas:  each  atomic  argument  in  the  conclusion  comes  directly  from 
an  atomic  argument  in  a  premise.  The  original  message-meaning  rules  involving 
encryption  carry  a  side-condition  that  the  principal  who  encrypted  the  message  is 
different  from  the  one  interpreting  it.  We  encode  this  explicitly  using  a  three-place 
encrypt  function  and  the  extra  distinct  function,  by  adding  an  extra  premise  to 
each  of  these  rules. 

There  is  one  nonce-verification  S-rule,  whereby  a  principal  can  determine  that 
some  message  was  sent  recently  by  examining  nonces: 


believes  (P,  said (Q,  X)) 

BAN4 :  believes  {P,fresh[X)) 

believes (P,  believes  (Q,X)) 

This  jurisdiction  S-rule  expresses  one  principal’s  trust  of  another: 


believes  (P,  controls (Q,X)) 

B AN5  Relieves  (P,  believes  ( Q ,  X)) 

believes  (P,  X) 

These  seven  S-rules  are  for  extracting  components  of  messages,  and  require 
knowledge  of  the  appropriate  keys  in  the  case  of  encrypted  messages.  The  last 
two  are  not  given  explicitly  in  the  BAN  paper  [BAN90],  but  they  are  necessary 
and  do  appear  in  a  technical  report  by  the  same  authors  [BAN89]. 


BAN6  : 


believes  (P,  shared. key  (K,  Q,  P)) 
sees(P ;  encrypt (X,  K ,  R)) 

sees(P,  X) 


BAN7: 


believes  (P,  public.key(K,  P)) 
sees(P,  encrypt (X,  K ,  R)) 


sees(P,X) 
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BAN8 


believes  ( P ,  public -key  (Ki ,  Q)) 
sees(P,  encrypt (X,  K2,R )) 
inv(Ki,K2 ) 


BAN9  : 


sees  (P,  X) 

sees(P,  combine(X,Y )) 


BAN10  : 


sees(P,  X) 

sees(P,  comma(X,  Y)) 


sees 


BAN11  believesiP,  said(Q,  comma(X,Y ))) 
believes  (P,  said (Q,X)) 

BAN12  •  iEl  fte^es(Q,  CQmma(^  y))) 

believes (P,  believes  (Q,X)) 

There  is  one  freshness  G-rule;  its  premise  precedes  its  conclusion  under  <ban. 
It  states  that  a  conjunction  is  fresh  if  any  part  of  it  is  fresh: 


BAN13 


believes  (P,  fresh(X )) 
believes  (P,  fresh(comma  ( X ,  Y)j) 


We  add  seven  related  freshness  G-rules:  four  to  reflect  the  fact  that  an  encrypted 
(or  combined)  message  is  fresh  if  either  the  body  or  the  key  is,  and  three  that 
extend  the  freshness  of  a  key  to  freshness  of  statements  about  that  key.  The  exam¬ 
ple  protocol  verifications  in  the  BAN  paper  require  some  of  these  extra  freshness 
rules,  and  they  are  alluded  to  in  the  technical  report.  We  include  the  rest  for  com¬ 
pleteness. 


BAN14  : 


believes  (P,  fresh  (K)) 


believes  (P,  fresh{shared-key  (K,  Q,R))) 


BAN15  : 


BAN16 


BAN1T : 


BANX8  : 


believes  ( P \  fresh(K) ) 


believes  (P,  fresh{publicJzey  ( K ,  Q))) 
believes  (P,  fresh(Y )) 
believes  (P,  fresh{secret(Y ,  Q,  R))) 
believes  (P,  fresh  (Y)) 
believes  (P,  fresh(cambine  (X,  Y))) 
believes  (P,  fresh  ( K ) ) 
believes  (P,  fresh(encrypt(X,  K,  R))) 
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BAN19 


BAN20 


believes  ( P ,  fresh(X )) 


believes (P,  fresh(encrypt(X,  K,R ))) 
believes  (P,  fresh(X )) 


believes  (P,  fresh(combine  (X,  K))) 

We  add  two  S-rules  that  do  the  work  of  message-meaning  and  nonce- 
verification  simultaneously: 


believes  (P,  fresh(K)) 
sees(P,  encrypt(X,  K,  R)) 
distinct (P,  R) 

_  *  believes (P,  shared. key (K,  Q,  P)) 

believes  (P,  believes  [Q,X)) 


believes  (P,  fresh  (Y ) ) 
sees(P,  combine (X,  Y)) 

BAN22  •  believes  secret(Y’  Q' P)) 
believes  (P,  believes  (Q,  X)) 

One  of  these  rules  is  implicitly  required  by  the  published  BAN  analysis  of  the 
Andrew  Secure  RPC  protocol. 

Finally,  since  we  represent  message  composition  explicitly  (via  comma), 
we  include  two  rewrites  that  express  the  commutativity  and  associativity  of  the 
comma  function;  three  more  rewrites  provide  commutativity  for  shared-key, 
secret,  and  distinct : 


comma(X,Y)  —  comma(Y,X) 
comma(comma(X,Y),  Z)  =  comma(X,  comma(Y,  Z)) 
believes (P,  shared -key  (K,  Q,  R))  =  believes  (P,  shared -key (K,  R,  Q)) 
believes  (P,  secret (Y,  Q,R ))  =  believes  (P,  secret (Y,  R,  Q)) 
distinct  (P,Q)  =  distinct  (Q,  P) 

We  have  shown  that  -<ban  satisfies  conditions  PI,  P2,  and  P3',  and  that  each  of 
the  rules  above  is  an  S-rule  or  a  G-rule.  All  the  rewrites  are  clearly  size-preserving, 
so  it  remains  only  to  show  that  the  S/G  restriction  holds.  Note  that  the  only  G-rules 
produce  conclusions  regarding  freshness.  Every  freshness  premise  will  therefore 
be  a  side-condition,  and  we  can  easily  check  that  each  of  these  is  no  larger  (in 
: <ban)  than  the  corresponding  conclusion,  so  the  S/G  restriction  is  satisfied,  and 
we  can  safely  apply  the  TG<  algorithm. 

Having  encoded  the  rules,  we  can  analyze  each  of  the  four  protocols  examined 
in  the  BAN  paper  and  check  all  the  properties  claimed  there  [BAN90]. 
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3,1,3  A  Simple  Example 

The  following  example  illustrates  how  the  BAN  rules  can  be  used  to  derive  prop¬ 
erties  of  a  simple  single-message  “protocol.”  This  protocol  requires  the  following 
initial  assumptions: 

believes  (B,  public -key  (Ka,  A)) 
believes  (B ,  fresh  (Ta) ) 
believes(B ,  controls(A,  secretly,  A,  B))) 
inv(Ka,  K~l) 

Here,  Y  is  a  variable,  and  A,  B,  K a,  K~l,  and  Ta  are  constants.  The  single 
message  is 

Message  1.  A  ->  B  :  {A,  B,  Ta,  Nab}Kb 

(We  use  the  notation  {M}k  to  indicate  encryption  of  the  message,  M,  using  the 
key,  K .)  We  “idealize”  this  message  by  converting  it  to  a  BAN  formula  including 
the  beliefs  it  is  meant  to  convey: 

sees(B,  encrypt(comma(Ta ,  secret(Nab,  A,  B)),  K~l ,  A)) 

First,  we  want  to  prove  that  B  believes  this  message  originated  from  A.  Applying 
Rule  2,  with  the  idealized  message  and  the  first  and  fourth  assumptions,  we  reach 
this  conclusion: 

believes  (B,  said(A ,  comma(Ta,  secret  (Nab,  A ,  B)))) 

In  order  to  derive  any  further  meaningful  beliefs  from  this  message,  we  must  show 
that  B  believes  that  A  currently  believes  it — that  it  is  not  a  replayed  message 
from  the  distant  past.  We  apply  one  of  the  freshness  rules  (13),  with  B’s  initial 
assumption  that  the  timestamp,  Ta,  is  fresh,  to  show  that  the  whole  message  is 
fresh: 

believes ( B ,  fresh(comma(Ta,  secret(Nab ,  A,  B )))) 

The  nonce- verification  rule  (4)  now  yields  that  B  believes  A  believes  the  message: 
believes(B,  believes(A,  comma(Ta,  secret (Nab,  A,  £?)))) 

Finally,  by  applying  the  first  rewrite  (commutativity  of  comma),  an  extraction  rule 
(12),  and  the  jurisdiction  rule  (5),  we  conclude  that,  after  receiving  this  message, 
B  believes  he  shares  the  secret,  Nab,  with  A: 

believes (B,  $ecret(Nab,  A,  B)) 

For  more  complex  examples,  see  the  original  BAN  papers  [BAN90,  BAN89]. 
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3.1.4  Kerberos 

Through  a  sequence  of  four  messages,  the  Kerberos  protocol  establishes  a  shared 
key  for  communication  between  two  principals,  using  a  trusted  server  [MNSS87]. 
The  simplified  concrete  protocol  assumed  in  the  original  BAN  analysis  is  the  fol¬ 
lowing: 

Message  1.  A—>S:A,B 

Message  2.  S  —>  A:  {Ts,  L,  Kab,  B,  {’. Ts ,  L,  Kab,  A}KJKas 
Message  3.  A  -*•  B  :  {T8,  L,  Kab,  A}Kbs,{A,  Ta}Kab 
Message  4.  B  -*•  A  :  {Ta  +  l}*a6 

Initially,  A  wants  to  establish  a  session  key  for  secure  communication  with  B.  A 
sends  Message  1  to  the  trusted  server,  S,  as  a  hint  that  she  wants  a  new  key  to  be 
shared  with  B.  The  server  responds  with  Message  2,  which  is  encrypted  with  KaB, 
a  key  shared  by  A  and  S.  In  this  message,  S  provides  the  new  shared  key,  Kab, 
along  with  a  timestamp  (Ts),  the  key’s  lifetime  (I),  B’s  name,  and  an  encrypted 
message  intended  for  B.  In  Message  3,  A  forwards  this  encrypted  message  along 
to  B,  who  decrypts  the  message  to  find  Kab  and  its  associated  information.  In 
addition,  A  sends  a  timestamp  (T„)  and  A’s  name,  encrypted  under  the  new  session 
key,  to  demonstrate  to  B  that  A  has  the  key.  Finally,  B  responds  with  Message  4, 
which  is  simply  Ta  + 1  encrypted  under  the  session  key,  to  show  A  that  B  has  the 
key  as  well. 

The  BAN  analysis  of  this  protocol  starts  by  constructing  a  three-message  ide¬ 
alized  protocol;  the  idealized  protocol  ignores  Message  1,  since  it  is  unencrypted 
and  thus  cannot  safely  convey  any  beliefs.  The  BAN  analysis  then  goes  on  to  list 
ten  initial  assumptions  regarding  client/server  shared  keys,  trust  of  the  server,  and 
freshness  of  the  timestamps  used  [BAN90].  We  express  each  of  these  three  mes¬ 
sages  and  ten  assumptions  directly  (the  conversion  is  purely  syntactic),  and  add 
four  more  assumptions  (see  Figures  3.2  and  3.3). 

The  first  extra  assumption — that  A  must  believe  its  own  timestamp  to  be 
fresh — is  missing  in  the  original  paper,  and  the  last  three  are  required  to  satisfy 
the  distinctness  side-conditions.  After  making  these  adjustments,  we  can  run  the 
14  initial  assumptions  and  3  messages  through  the  TG#  algorithm,  and  it  produces 
an  additional  50  true  formulas. 
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Message  2. 


S^A:{T„a£^B,{T„aJ^  B}kJk„ 

sees  (A,  encrypt ( comma ( comma (Ts ,  shared. key  (Kab,  A,  B)), 

encrypt  (comma(Ts,  shared. key  (Kab,  A 


^,5)) 


Message  3.  A^B:{T„aM  B}Kbs,  {Ta,  A  AA  B}Kab  from  A 

sees(B,comma(encrypt(comma(T3,shared.key(Kab,A,B)),Ki,s,S), 

encrypt(comma(Ta,shared.key(Kab,A,B)),Kab,A))) 

Message  4.  B  *=>  A  :  {Ta,  A  B}Kab  from  B 

sees(A,  encrypt ( comma (Ta ,  shared., key (Kab,  A,  B)),Kab,  B)) 


Figure  3.2:  Kerberos  protocol  messages,  in  BAN  idealized  form  and  converted  to 
the  syntax  of  our  encoding. 

believes  (A,  shared  Jcey(Kaa,  S,  A)) 

believes  (B,  shared  .key  (Kbs,  S,  B)) 

believes  (S,  shared -key  (Ka3 ,  A,  S)) 

believes (S,  shared. key (Kbs,  B,  S )) 

believes  (S,  shared. key  (Kab,  A,  B )) 

believes  (A,  controls (S,  shared. key  (Kab,  A,  B))) 

believes  (B,  controls (S,  shared. key (Kab,  A,  B))) 

believes  (A,  fresh(T3)) 

believes  ( B ,  fresh(Ts ) ) 

believes  ( B ,  fresh(Ta)) 

believes  (A,  fresh(Ta )) 
distinct  (A,  S) 
distinct  (A,  B) 
distinct  (B,  S) 

Figure  3,3:  Encoding  of  the  Kerberos  initial  assumptions.  All  but  the  last  four 
assumptions  appear  in  the  BAN  analysis  [BAN90]. 
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By  running  the  simple  decision  procedure  described  in  Chapter  2,  we  can  ver¬ 
ify  that  these  four  desired  properties  hold: 

believes  (A,  shared  Jcey  (Kab,  A ,  B)) 
believes  ( B ,  shared  Jcey(Kab,  A ,  B )) 
believes (B,  believes  (A,  shared  Jcey(Kab,  A,  B))) 
believes  (A,  believes  (B,  shared  Jcey  (Kab,  A,  B ))) 

These  results  agree  with  the  original  BAN  analysis.  They  indicate  that  each  of  the 
two  parties  believes  it  shares  a  key  with  the  other,  and  that  each  believes  that  the 
other  believes  the  same  thing. 

If  we  remove  the  optional  final  message  from  the  protocol  and  run  the  algo¬ 
rithm  again,  it  generates  41  valid  formulas.  By  computing  the  difference  between 
this  set  and  the  first  set  of  50,  we  can  determine  exactly  what  the  final  message 
contributes.  Among  the  9  formulas  in  this  difference  is 

believes(A,  believes  (B,  shared  Jcey  (Kab,  A,  B))) 

(the  last  of  the  four  results  above).  This  confirms  the  claim  in  the  original  analysis 
that  “the  three-message  protocol  does  not  convince  A  of  B’s  existence”  [BAN90]. 
This  technique  of  examining  the  set  difference  between  the  deduced  properties  of 
two  versions  of  a  protocol  is  a  simple  but  powerful  benefit  of  the  theory  generation 
approach;  it  helps  in  understanding  differences  between  protocol  variants  and  it 
supports  rapid  prototyping  during  protocol  design. 

In  the  context  of  the  Kerberos  protocol  and  the  BAN  logic,  we  illustrate  here 
a  single  step  in  the  TG^  algorithm,  showing  how  a  new  formula  gets  added  to  the 
fringe.  After  several  iterations  of  the  closure  function  are  completed,  there  are  37 
formulas  in  the  known-valid  set.  Of  these,  16  are  in  the  fringe,  including  this  one: 

believes  (B,  said(S)  comma(Ts ,  shared  Jcey  (Kab,  A,  B)))) 

This  formula  unifies  with  the  first  premise  of  the  “nonce-verification”  S-rule  (4), 
so  we  apply  its  unifier  to  the  second  premise  of  that  rule,  yielding 

believes  (B,fresh(comma(Ts,  shared  Jcey  (Kab,  A,  B )))) . 

None  of  the  37  formulas  unifies  directly  with  this  additional  premise,  so  we  at¬ 
tempt  to  work  backwards  from  it,  using  G-rules  and  rewrites.  If  we  apply  the  first 
freshness  G-rule  (13)  in  reverse,  we  get 

believes  ( B,fresh(Ts )), 
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which  is  one  of  the  initial  assumptions  of  the  protocol  (and  thus  one  of  the  37 
known  formulas).  Since  all  premises  for  the  nonce- verification  rule  have  now 
been  matched,  we  insert  its  (instantiated)  conclusion  into  the  new  fringe: 

believes  (B,  believes(S,  comma(Ts,  shared  -key  (Kab,  A,  B)))). 

This  newly  derived  formula  represents  the  fact  that  B  now  believes  that  S  cur¬ 
rently  believes  in  this  message  B  has  received, 

3.1.5  Andrew  RPC,  Needham-Schroeder,  and  CCITT  X.509 

We  encode  the  assumptions  and  messages  of  the  three  variants  of  the  Andrew 
secure  RPC  handshake  protocol  given  in  the  BAN  paper,  and  the  TG^  algorithm 
produces  the  expected  results.  The  last  of  these  verifications  requires  an  extra 
freshness  assumption  not  mentioned  in  the  BAN  analysis: 

believes  (B,fresh(Kab')) 

It  also  requires  one  of  the  added  freshness  rules  (14)  and  one  of  the  simultaneous 
message-meaning/nonce-verification  rules  (21). 

We  can  also  duplicate  the  BAN  results  for  two  variants  of  the  Needham- 
Schroeder  public-key  secret-exchange  protocol.  Finally,  we  have  run  the  algo¬ 
rithm  on  two  variants  of  the  CCITT  X.509  protocol  explored  in  the  BAN  paper. 
One  of  these  checks  failed  to  produce  the  expected  results,  and  this  led  to  the 
discovery  of  an  oversight  in  the  BAN  analysis:  they  observe  a  weakness  in  the 
original  X.509  protocol  and  claim,  “The  simplest  fix  is  to  sign  the  secret  data  Ya 
and  Yfc  before  it  is  encrypted  for  privacy.”  In  fact  we  must  sign  the  secret  data 
together  with  a  nonce  to  ensure  freshness.  We  replace  the  occurrence  of  Ya  in  the 
original  protocol  by 


encrypt(comma(Ya,  Ta),  K'a,  A) 

and  the  occurrence  of  Yt  by 

encrypt (comma(Yb,  Ng),  Kj,,  B) . 

After  correcting  this,  the  verifications  proceed  as  expected. 

The  full  encodings  of  these  protocols  appear  in  Appendix  B, 
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3.2  AUTLOG 

AUTLOG  is  an  extension  of  the  BAN  logic,  proposed  by  Kessler  and  Wedel 
[KW94].  It  incorporates  several  new  concepts,  some  of  which  appear  in  other 
BAN  variants,  such  as  the  GNY  logic  developed  by  Gong,  Needham,  and  Ya- 
halom  [GNY90].  It  allows  analysis  of  a  simulated  eavesdropper  for  detecting 
some  information  leaks,  uses  the  notion  of  principals  “recognizing”  decrypted 
messages,  and  introduces  a  “recently  said”  notion  which  is  more  precise  than 
BAN’S  beliefs  about  beliefs. 

The  encoding  of  AUTLOG  uses  all  the  BAN  functions,  and  a  few  extras,  listed 
in  Figure  3.4.  The  original  rules  of  inference  from  AUTLOG  can  be  entered  al- 


Function 

recognizable  (X ) 
mac(K,  X) 
hash(X) 

recently  .said(P,  X) 


Figure  3.4:  Extra  AUTLOG  functions 

most  verbatim.  There  are  23  S-rules  and  19  G-rules;  the  rules  governing  freshness 
and  recognition  are  the  only  G-rules.  The  full  set  of  rules  appears  in  Appendix  B. 

In  applying  the  TG^  algorithm,  we  can  use  a  similar  pre-order  for  AUTLOG 
to  that  used  for  the  BAN  logic  ban )•  AUTLOG  has  one  wrinkle,  however,  that 
requires  a  modification  to  this  pre-order.  In  AUTLOG,  there  are  rules  like  the 
following: 

believes  (P,  shared. key  (K,  Q,  P )) 
sees(P ,  encrypt (X,  K,  R)) 
believes(P recognizable (X)) 

believes (P,  said(Q ,  encrypt(X,  K ,  R))) 

Under  -<ban  >  the  conclusion  of  this  rule  is  larger  than  any  of  its  premises.  We  can 
see  from  examining  the  rules,  though,  that  this  rule  will  not  lead  to  formulas  of 
unbounded  size,  so  we  try  changing  the  pre-order.  Essentially,  we  want  to  collapse 
the  believes-said-encrypt  sequence  and  treat  it  as  equivalent  to  sees-encrypt.  In 
order  to  do  this,  we  define  a  partial  order  on  function  names  (□),  and  define  a  new 
nsyms  function  recursively: 

function  nsyms  (F,  g)  = 
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if  F  is  a  variable  or  0-ary  function  (constant)  then 
return  1 

else  (F  must  have  the  form  f(Fi,..,,Fn)) 

args  <—  {F*  |  Ftis  not  in  an  atomic  argument} 
sum  =  t,F'eargs  nsyms(F',  f ) 

if  /  C  g  then 
return  sum 
else 

return  1  +  sum 

We  can  then  define  the  pre-order  as  follows: 

F  ; <AUTLOG  G  =  (Vv.occ(v,  F)  <  occ(v,G)) 

A  (Vf.Vcr,nsyms(crF,  f)  <  nsyms(aG,  /)) 

The  proof  that  this  pre-order  satisfies  conditions  P1-P3  is  similar  to  that  in  the 
BAN  case, 

To  check  a  protocol  for  leaks  using  AUTLOG,  one  finds  the  consequence  clo¬ 
sure  over  the  “seeing”  rules  of  the  transmitted  messages.  The  resulting  list  will 
include  everything  an  eavesdropper  could  see.  The  TG^  algorithm  is  well-suited 
to  computing  this  list;  the  seeing  rules  are  all  S-rules,  so  the  algorithm  will  gener¬ 
ate  exactly  the  desired  list. 

Kessler  and  Wedel  present  two  simple  challenge-response  protocols:  one  in 
which  only  the  challenge  is  encrypted  and  another  in  which  only  the  response  is 
encrypted.  We  have  encoded  both  of  these  protocols  and  verified  the  properties 
Kessler  and  Wedel  claim:  that  both  achieve  the  authentication  goal 

believes (B,  recently said(A,  Rb)) 

where  Rb  is  the  secret  A  provides  to  prove  its  identity.  Furthermore,  through 
the  eavesdropper  analysis  mentioned  above,  we  can  show  that  in  the  encrypted- 
challenge  version,  the  secret  is  revealed  and  thus  die  protocol  is  insecure.  (Hie 
BAN  logic  cannot  express  this.) 

We  have  also  checked  that  the  Kerberos  protocol,  expressed  in  AUTLOG, 
satisfies  properties  similar  to  those  described  in  Section  3.1. 

3.3  Kailar’s  Accountability  Logic 

More  recently,  Kailar  has  proposed  a  simple  logic  for  reasoning  about  account¬ 
ability  in  electronic  commerce  protocols  [Kai96].  The  central  construct  in  this 
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logic  is 

P  CanProve  X 

which  means  that  principal  P  can  convince  anyone  in  an  intended  audience  shar¬ 
ing  a  set  of  assumptions,  that  X  holds,  without  revealing  any  “secrets”  other  than 
X  itself. 

Kailar  provides  different  versions  of  this  logic,  for  “strong”  and  “weak”  proof, 
and  for  “global”  and  “nonglobal”  trust.  These  parameters  determine  what  evi¬ 
dence  will  constitute  an  acceptable  proof  of  some  claim.  The  logic  we  choose 
uses  strong  proof  and  global  trust,  but  the  other  versions  would  be  equally  easy  to 
encode.  The  encoding  uses  these  functions:  CanProve,  IsTrustedOn,  Implies, 
Authenticates,  Says,  Receives,  SignedWith,  comma,  and  inv. 

We  encode  the  four  main  rules  of  the  logic  as  follows: 

CanProve(P,  X),  CanProve(P,Y ) 

CanProve  (P,  comma  ( X ,  Y ) ) 

CanProve(P,X),  Implies(X,Y) 

CanProve(P,  Y) 

Receives(P,  SignedWith(M,  K~1)) 

CanProve{P,  Authenticates  (K,  Q)) 

Si  _ I«v(K,K->) _ 

CanProve(P,Says(Q,M)) 

CanProve(P,  Says(Q ,  X)) 

CanProve(P,  IsTrustedOn(Q,X)) 

US  CanProve(P,  X) 

The  Conj  and  Inf  rules  allow  building  conjunctions  and  using  initially-assumed 
implications.  The  Sign  and  Trust  rules  correspond  roughly  to  the  BAN  logic’s 
public-key  message-meaning  and  jurisdiction  rules.  We  can  again  use  <ban  as 
the  pre-order.  This  makes  Conj  a  G-rule;  the  other  three  are  S-rules.  There  are  a 
total  of  six  S-rules,  one  G-rule,  and  three  rewrites  in  our  encoding  of  this  logic; 
the  extra  S-rules  and  rewrites  do  simple  comma-manipulation. 

We  can  replace  the  construct 


X  in  M 

(representing  interpretation  of  part  of  a  message)  with  three  explicit  rules  for  ex¬ 
tracting  components  of  a  message.  We  add  rewrites  expressing  the  commutativity 
and  associativity  of  comma,  as  in  the  other  logics. 
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IBS  protocol  messages: 

Message  3.  E  —*  S  :  {{Price} K-i,  Price}  K-i 

Receives(S,  SignedWith(comma(SignedWith(Price,  Kjl), 

Price), 

K-1)) 

Message  5.  S  — ♦  E  :  {Service}  Kji 

Receives (E,  SignedWith(Service ,  K~1)) 

Message  6.  E  =>  S  :  {ServiceAck}  K-% 

Receives (S,  SignedWith(ServiceAck,  K~1)) 

Initial  assumptions: 

CanProve(S,  Authenticates ( Ke ,  E)) 

Implies  (Says  (E,  Price),  AgreesToPrice(E ,  pr)) 

Implies  (Says  (E,  ServiceAck),  ReceivedOneServiceltem(E)) 

Figure  3.5:  Excerpt  from  IBS  protocol  and  initial  assumptions. 


We  have  verified  the  variants  of  the  IBS  (NetBill)  electronic  payment  proto¬ 
col  that  Kailar  analyzes  [Kai96].  Figure  3.5  contains  an  encoding  of  part  of  the 
“service  provision”  phase  of  the  asymmetric-key  version  of  this  protocol.  The 
customer,  E,  first  sends  the  merchant,  S,  a  message  containing  a  price  quote, 
signed  by  the  merchant;  this  message  is  itself  signed  by  the  customer  to  indicate 
his  acceptance  of  the  quoted  price.  The  merchant  responds  by  providing  the  ser¬ 
vice  itself  (some  piece  of  data),  signed  with  her  private  key.  The  last  message  of 
this  phase  is  an  acknowledgement  by  the  customer  that  he  received  the  service, 
signed  with  the  customer’s  private  key. 

When  we  run  the  TG*  algorithm  on  these  messages  and  assumptions,  it  applies 
the  Sign  rule  to  produce  these  two  formulas: 

CanProve(S ,  Says(E,  comma(SignedWith(Price,  K~l),  Price))) 
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CanProve(S,  Says(E,  ServiceAck )). 

These  conclusions  are  not  particularly  noteworthy  in  their  own  right;  they  reflect 
the  fact  that  S  (the  seller)  can  prove  that  E  (the  customer)  has  presented  two 
specific  messages.  With  these  formulas,  the  TG^  next  applies  a  comma-extracting 
rule  to  produce 

CanProve(S,  Says(E,  SignedWith(Price,  K^1))) 

CanProve(S,  Says(E,  Price)). 

This  shows  that  S  can  prove  E  sent  individual  components  of  the  earlier  messages. 
Finally,  TG^  applies  Inf  to  derive  these  results,  which  agree  with  Kailar’s  [Kai96]: 

CanProve(S,  Says(E,  ReceivedOneServiceltem(E))) 

CanProve(S,  Says(E,  AgreesToPrice(E,  pr ))) 

These  represent  two  desired  goals  of  the  protocol:  that  the  seller  can  prove  the  cus¬ 
tomer  received  the  service,  and  that  the  seller  can  prove  what  price  the  customer 
agreed  to.  The  TG^  algorithm  stops  at  this  point,  since  no  further  rule  applications 
can  produce  new  formulas. 

We  have  verified  the  rest  of  Kailar’s  results  for  two  variants  of  the  IBS  protocol 
and  for  the  SPX  Authentication  Exchange  protocol.  The  full  encodings  of  these 
protocols  appear  in  Appendix  B. 


3.4  Summary 

In  this  chapter,  we  have  shown  how  theory  generation  can  be  applied  to  several 
existing  logics  for  protocol  analysis,  and  successfully  reproduced  manual  verifi¬ 
cation  results  for  assorted  protocols.  The  table  in  Figure  3.6  contains  some  results 
of  these  applications  of  theory  generation.  Each  line  in  the  table  shows,  for  a 
given  protocol,  the  number  of  initial  assumptions  and  messages  fed  to  the  TG^ 
algorithm,  and  the  number  of  formulas  in  the  theory  representation  it  generated. 
In  each  case,  we  were  able  to  use  theory  generation  to  prove  that  the  protocols 
satisfied  (or  failed  to  satisfy)  various  desired  belief  properties.  Note  that  the  gen¬ 
erated  theory  representations  typically  contained  on  the  order  of  several  dozens  of 
formulas. 

The  mere  fact  that  certain  desired  properties  of  a  protocol  are  derivable  in  one 
of  these  belief  logics  does  not  imply  that  no  attacks  exist.  The  rules  of  each  logic 
incorporate  various  assumptions,  such  as  “perfect  encryption”  and  constraints  on 
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Logic 

Protocol 

Assumps. 

Msgs. 

Th.  Rep. 

BAN 

Kerberos 

14, 13 

3 

61,52 

Andrew  RPC 

8,8,7 

4 

32,  39,  24 

Needham-Schroeder 

19, 19 

5 

41,41 

CCITT  X.509 

13, 12 

3 

69, 74 

Wide-Mouth  Frog 

12, 12 

2 

34, 34 

Yahalom 

9,17,17 

5 

40, 60, 62 

AUTLOG 

challenge-response  1 

2 

2 

10 

challenge-response  2 

4 

2 

13 

Kerberos 

18 

3 

79 

SKID 

8 

2 

12 

Kailar’s 

Accountability 

IBS  variant  1 

14 

7 

44, 39 

IBS  variant  2 

20 

7 

46, 52 

SPX  Auth.  Exchange 

18 

3 

36 

Figure  3.6:  Protocol  analyses  performed  with  existing  belief  logics,  with  the  num¬ 
ber  of  formulas  in  the  initial  assumptions,  messages  transmitted,  and  generated 
theory  representation.  (Some  analyses  involved  several  variations  on  the  same 
protocol.) 


how  messages  can  be  broken  up  and  reconstituted.  Beyond  this  limitation,  the 
logics  are  not  designed  to  address  every  form  of  attack.  BAN,  for  instance,  cannot 
express  the  property  that  secrets  are  not  leaked.  In  Chapter  5,  we  explore  further 
uses  of  theory  generation  for  protocol  analysis.  In  particular,  we  work  with  a  new 
logic  (introduced  in  Chapter  4)  that  allows  more  comprehensive  protocol  analy¬ 
ses,  allowing  more  confidence  in  protocols  that  pass  its  checks.  We  also  examine 
applications  of  theory  generation  beyond  simple  property-checking.  Details  re¬ 
garding  the  implementation  and  performance  of  the  system  used  to  produce  these 
results  appear  in  Chapter  6. 
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Chapter  4 

Interpretation  and  Responsibility 


Using  theory  generation  with  existing  logics  as  described  in  Chapter  3,  we  can 
quickly  check  the  standard  belief  properties  of  protocols  described  in  the  con¬ 
ventional  ‘‘idealized”  form.  There  are,  however,  many  other  questions  about  a 
protocol  that  we  might  want  to  answer,  so  it  is  reasonable  to  ask  whether  the  same 
technique  could  be  applied  to  a  wider  class  of  properties,  or  to  different  forms 
of  protocol  description.  Ideally,  we  would  endow  a  protocol-verification  system 
with  a  larger  toolkit  of  analyses  without  requiring  from  the  user  undue  amounts 
of  extra  information  or  patience. 

In  this  chapter,  we  consider  several  new  kinds  of  checks  such  a  system  can 
perform  at  relatively  low  cost  Taken  individually,  each  of  these  checks  can  pro¬ 
vide  more  confidence  in  a  protocol,  and  when  applied  together  and  in  concert  with 
traditional  belief  checks,  they  complement  one  another  to  form  a  unified  and  more 
comprehensive  analysis. 

We  first  discuss  a  way  to  more  fully  formalize  the  process  of  interpreting  mes¬ 
sages  (Section  4.1);  this  will  allow  us  to  reason  about  protocols  at  a  more  concrete 
level.  We  present  the  formalization  in  the  context  of  a  new  belief  logic,  RV,  which 
borrows  concepts  and  rules  from  the  BAN,  GNY,  and  AUTLOG  logics.  Next  we 
introduce  two  classes  of  properties,  honesty  and  secrecy,  which  rely  on  the  for¬ 
malized  interpretations  and  can  expose  flaws  not  addressed  by  the  belief  logics 
considered  earlier.  The  honesty  properties  restrict  the  messages  that  a  principal 
may  safely  “sign,”  to  prevent  the  messages’  recipients  from  reaching  faulty  con¬ 
clusions,  The  secrecy  properties  regulate  the  disclosure  of  information  to  other 
parties,  and  also  depend  critically  on  explicit  interpretation.  A  participant  in  a 
protocol  who  satisfies  both  honesty  and  secrecy  properties  is  said  to  be  “responsi¬ 
ble.”  We  claim  that  demonstrating  the  responsibility  of  participants  in  a  protocol 
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is  a  necessary  counterpart  to  proving  traditional  belief  properties. 


4.1  Interpretation 

The  BAN-style  belief  logics  allow  protocol  designers  to  think  about  a  protocol  at  a 
convenient  level  of  abstraction;  however,  the  gap  between  the  “idealized”  protocol 
and  a  typical  concrete  protocol  implementation  is  substantial.  The  idealization 
step  is  widely  recognized  as  a  liability  of  these  logics  [Syv91,  NS93,  MB94].  It 
is  an  informal  process;  we  typically  write  the  concrete  protocol  side-by-side  with 
a  proposed  idealized  version,  and  then  attempt  to  derive  desired  properties.  When 
these  derivations  fail,  we  augment  the  idealized  messages  with  extra  statements  or 
introduce  additional  initial  assumptions.  In  each  case  the  burden  is  on  the  (human) 
verifier  to  ensure  that  the  additions  are  “safe.”  Finally,  with  no  formal  description 
of  concrete  messages,  the  implicit  assumptions  about  their  form,  such  as  whether 
keys  and  nonces  are  distinguishable,  are  easily  forgotten  or  left  unspecified. 

The  original  BAN  analysis  of  the  Needham/Schroeder  public  key  protocol 
used  a  bad  idealization  that  went  undetected  until  Lowe  found  a  flaw  in  the  pro¬ 
tocol  and  demonstrated  it  using  model  checking  methods  [Low95,  Low96].  The 
flaw  escaped  detection  for  more  reasons  than  the  bad  idealization — we  will  look 
at  these  reasons  closely  in  Section  4.2 — but  the  idealization  was  certainly  flawed. 
The  fact  that  the  fix  Lowe  proposed  cannot  even  be  expressed  in  the  idealized 
level  indicates  the  need  for  more  concrete  grounding  of  BAN-style  reasoning.  We 
discuss  this  flaw  and  its  connection  to  idealization  in  Sections  4.2.3  and  4.3.2. 

4.1.1  Possible  Approaches 

Several  approaches  to  bridging  this  idealization  gap  have  been  proposed  or  de¬ 
serve  consideration. 

Abadi  and  Needham  provide  a  set  of  practical  guidelines  for  constructing 
good  idealizations  (or  conversely,  constructing  good  concrete  protocols)  [AN96]. 
Though  they  are  instructive  and  merit  careful  consideration,  these  guidelines  are 
not  amenable  to  formal  verification.  Furthermore,  as  the  authors  acknowledge, 
they  are  neither  necessary  nor  sufficient.  Since  the  principles  are  often  legiti¬ 
mately  violated  in  practice,  it  is  hard  to  identify  the  truly  improper  idealizations 
that  lead  to  problems. 

We  could  take  a  somewhat  more  drastic  approach  and  abandon  the  idealized 
level  of  protocol  description  completely.  By  working  solely  at  the  concrete  level, 
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we  avoid  having  to  assign  meanings  to  messages,  This  is  what  recent  verification 
techniques  based  on  model  checking  do  [Low96,  MMS97,  MCJ97].  While  this 
approach  has  the  appeal  of  producing  counterexamples  and  not  requiring  the  con¬ 
struction  of  idealizations,  it  does  have  some  disadvantages.  With  no  formal  notion 
of  the  “meaning”  of  a  message,  we  can  no  longer  reason  about  belief,  which  is  a 
natural  notion  in  the  context  of  authentication.  We  can  analyze  data  flow:  secrets 
successfully  communicated,  information  leaked,  and  so  on,  and  we  can  check  the 
correspondence  properties  defined  by  Woo  and  Lam  [WL93],  but  the  richer  and 
perhaps  more  intuitive  belief  properties  are  out  of  reach.  We  cannot  factor  out  the 
abstract  core  of  a  protocol  from  its  various  possible  implementations,  and  there  is 
little  indication  of  why  a.  protocol  works. 

Mao  has  proposed  a  method  of  developing  idealizations  in  a  principled  way 
[Mao95],  by  breaking  the  idealization  process  down  into  a  sequence  of  incremen¬ 
tal  steps,  each  of  which  can  be  justified  individually.  The  approach  described  be¬ 
low  is  more  suitable  for  automation  via  theory  generation,  and  can  more  directly 
express  the  desired  qualities  of  idealizations. 

Many  of  the  problems  with  idealizations  result  from  idealized  messages  con¬ 
taining  more  information  than  their  concrete  counterparts,  which  leads  to  ambigu¬ 
ous  mappings  from  concrete  to  idealized  messages.  We  could  solve  this  problem 
by  establishing  a  single  one-to-one  mapping  for  all  protocols,  for  instance  using  an 
ASN.l  notation  [ASN94].  This  leads  to  larger  messages;  in  most  environments 
today,  public-key  encryption  is  expensive  relative  to  other  costs  of  communica¬ 
tion,  so  increased  message  size  may  be  unacceptable.  (This  problem  is  smaller 
with  elliptic-curve  cryptography,  since  it  can  be  implemented  more  efficiently 
than  traditional  public-key  methods.)  More  importantly,  this  technique  imposes 
significant  constraints  on  the  form  of  the  concrete  protocol,  so  few  existing  proto¬ 
cols  would  be  accepted,  even  if  the  concrete-to-abstract  mapping  were  protocol- 
dependent.  Finally,  this  approach  only  solves  the  ambiguous-interpretation  prob¬ 
lem;  the  protocol  designer  must  still  devise  an  idealized  protocol. 

4.1.2  The  RV  Logic  core 

Before  describing  the  formalization  of  explicit  interpretations,  we  present  here 
the  core  of  a  new  belief  logic,  RV  (for  Responsibility  Verification ),  on  which  those 
interpretations  will  be  built.  The  core  rules  and  operators  of  fins  logic  are  very 
similar  to  those  of  BAN,  AUTLOG,  and  GNY;  the  significant  new  features  are 
introduced  in  the  sections  that  follow. 

Figure  4.1  shows  the  functions  and  predicates  available  in  the  RV  core.  The 
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Function 

Notation 

Meaning 

believes(P,X) 

P  |=  X 

P  believes  X 

sees(P,X) 

P<X 

P  has  seen  message  X 

said(P,X ) 

P\^X 

P  uttered  X  at  some  time 

says(P,X) 

PfcX 

P  uttered  X  “recently” 

controls  (P,  X) 

P  controls  X 

P  is  an  authority  on  X 

fresh(X ) 

#P0 

X  was  first  used  in  this  run 

shared -key  (K,  P,  Q ) 

P  Q 

P  and  Q  share  key  K 

public -key [K,  P ) 

JK  j~\ 

\ — >  P 

P’s  public  key  is  K 

secret  (Y,  P,  Q) 

P  and  Q  share  secret  Y 

encrypt  (X,  K) 

{X)k 

X  encrypted  under  key  K 

inv(Ki,K2) 

Ti  =  K? 

public/private  key  pair 

inly,  X) 

YinX 

Y  occurs  in  X 

comma(X,  Y) 

(X,Y) 

conjunction 

A,B,S,T,.. . 

A,B,S,T,... 

0-ary  functions  (constants) 

Figure  4.1 :  Core  functions  of  RV 

full  function  names  are  in  the  left  column,  but  we  use  the  traditional  concise  no¬ 
tation  in  the  center  column  when  describing  the  rules.  All  of  these  functions  ap¬ 
pear  in  the  BAN  logic  encoding  (Section  3.1),  with  the  exceptions  of  says  and  in. 
The  says  function,  also  found  in  AUTLOG,  expresses  that  a  principal  has  recently 
sent  some  message,  whereas  said  only  ensures  that  the  principal  uttered  it  at  some 
time.  In  BAN  the  says  notion  is  subsumed  by  believes,  in  that  P  )=  Q  X  (“P 
believes  Q  says  X”)  is  written  as  P  ^  Q  ^  X  (“P  believes  Q  believes  X”).  The 
in  function,  similar  to  one  in  GNY,  indicates  that  one  message  is  part  of  another 
message.  Note  that  the  combine  operator  has  been  removed;  this  is  discussed 
below. 

RV  has  the  following  three  message-meaning  S-rules.  As  in  BAN,  they  allow 
one  principal  to  determine  who  sent  a  given  message.  Shared-secret  authentication 
is  achieved  without  an  explicit  secret-combining  operator  ((Y)y);  the  presence  of 
a  shared  secret  anywhere  in  a  message  is  sufficient  to  authenticate  it.  This  change, 
also  made  in  GNY,  simplifies  the  honesty  properties  described  later. 

PWQ^(X,K) 
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RV2  : 


p^&Q  p<{x}K9  Ki^iq 
‘  '  p  N  Q  h-  x 

nP^Q^P  P<X  Y  inX 


T>\ro  .  I —  ™  ^  ^ 

' - p¥qFx - 

The  nonce-verification  S-rule  allows  a  principal  to  determine  that  a  message 
was  sent  recently  if  it  believes  it  is  fresh: 


RV4  : 


P_tQ  Kg  PN#W 
P>  Q  |w  X 


Using  the  jurisdiction  S-rule,  a  principal  gains  a  new  belief  based  on  a  recent 
statement  by  a  party  it  considers  an  authority  on  the  matter  in  question: 


RV5  : 


P  )=  Q  controls  X 

_p_ 


In  RV,  as  in  AUTLOG,  a  principal  “sees”  every  statement  it  believes.  This  G-rule 
makes  the  decryption  rules  simpler: 


RV6  : 


P^X 

P<X 


We  add  this  introspection  rule,  similar  to  one  appearing  in  the  SVO  logic. 


RV7 


P<X 

P^P<X 


A  principal  can  decrypt  any  message  whose  key  it  has  seen  using  these  S-rules: 


RV8 


P<  Q^Up  P< |  {X}j 
P<X 


P<  A  P  P<  {X}K 
P<X 


.  P<  &  Q  P<  W*.  ft  -  K,1 

P<X 

These  S-rules  provide  decomposition  of  compound  messages  built  with  comma 
(the  in  function  is  introduced  below  in  RV22). 
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XmM  P^Q^M  XinM 

PWQ'rX  •  P^Q^X 


We  include  a  complete  set  of  G-rules  for  determining  the  freshness  of  a  message 
given  the  freshness  of  one  if  its  components: 


RV14  : 


pt#m 

P£#((X,Y)) 


RV15: 


RV16: 


PW#(K) 

PW#{&Q) 


R.V17 : 


p_t#m 

P  N  #  (q  &  Rj 


RV18  : 


P^*(K) 

pN#(Wk) 


RV19 : 


pN#(Wk)  ~ 


RV20  .  P^#(X)  P<&_Q  p  <  k2  =  AT1 

PN#  (W*,) 

P<Q^R 

RV21 '  pFIPU - 


Finally,  this  G-rule,  whose  premise  is  empty,  allows  us  to  determine  when  one 
message  is  part  of  a  larger  message.  Note  that  in  only  “looks  inside”  the  comma 
function,  and  not  encrypt  or  any  others.  The  reasons  for  this  will  become  clear  in 
the  following  sections. 


RV22  : 


X  in  (X,  Y) 


The  following  equivalences  express  the  usual  associative  and  commutative 
properties  of  comma  and  other  operators. 


(X,Y)  =  (Y,X) 

((X  ,Y),Z)  =  (X,(Y,Z)) 
(Q^R)  =  (RAQ) 

(Q^R)  =  (R^Q) 
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4.1,3  Concrete  Message  Syntax 

To  properly  formalize  the  mapping  of  concrete  messages  to  abstract  messages,  we 
must  of  course  carefully  specify  the  form  concrete  messages  take.  This  requires 
striking  a  balance  between  allowing  flexibility  in  implementations  and  permitting 
tractable  verification.  We  will  assume  messages  are  composed  of  atoms  (such  as 
nonces,  keys,  and  principal  names),  combined  by  concatenation  and  encryption. 
We  introduce  a  new  RV  concatenation  operation,  [X.Y]  (see  Figure  4.2).  The  con- 


Function  Notation 

Meaning 

dot(X,Y)  [X.Y] 
nil  [] 

concatenation 

concatenated  list  terminator 

Figure  4.2:  Extra  functions  of  RV  for  supporting  concrete  messages. 

catenation  operator  is  ordered:  [X.Y]  and  [7.X]  are  distinguishable,  as  they  would 
be  in  typical  implementations.  We  will  make  the  usual  “perfect  cryptography”  as¬ 
sumptions:  {X}K  can  only  be  produced  by  a  principal  who  knows  {X}k  or  both 
X  and  K,  and  seeing  {X}k  reveals  no  information  about  X  or  K  to  a  principal 
who  does  not  know  K.  We  assume  that  the  implementation  can  identify  where 
each  atom  begins  and  ends,  so  a  principal  expecting  message  [X.F]  will  reject  a 
message  [Nl]  or  [iVl.  jV2.JV3],  and  if  it  receives  [JV1.JV2],  will  always  match  jVl 
to  X  and  JV2  to  Y  rather  than  splitting  the  message  elsewhere.  We  also  assume 
that  decrypting  a  message  with  the  wrong  key  will  yield  results  distinguishable 
from  any  normal  message.  We  could  eliminate  this  last  assumption,  if  necessary, 
by  introducing  a  recognizable  operator  as  in  AUTLOG, 

To  give  concrete  messages  the  properties  described  above,  we  need  a  canonical 
representation  for  messages  containing  sequences  of  atoms,  so  we  introduce  a 
nil  atom  and  using  the  Lisp  list-building  convention.  For  convenience,  we  write 
[X.  [Y.  [,Z.m/]]]  as  [X.Y.Z].  We  require  every  concrete  message  in  a  protocol 
description  to  be  constructed  as  follows: 

•  The  special  constant  nil  is  a  valid  concrete  message. 

•  If  X  is  a  constant  and  M  is  a  valid  concrete  message,  then  [ X.M ]  is  a  valid 
concrete  message. 

•  If  M  is  a  valid  concrete  message  and  K  is  a  constant,  then  {M}K  is  a  valid 
concrete  message. 
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We  do  not  assume  that  keys,  nonces,  and  principal  names  are  always  distin¬ 
guishable,  that  principals  always  recognize  their  own  messages,  or  that  compo¬ 
nents  of  message  j  are  always  distinguishable  from  components  of  message  k 
( k  7^  j).  In  environments  where  some  or  all  of  these  assumptions  are  safe,  we  can 
easily  apply  them  by  having  the  verification  tool  automatically  tag  message  com¬ 
ponents  with  their  types.  Finally,  we  must  extend  the  rules  for  deducing  freshness 
and  determining  (X  in  Y)  to  accommodate  the  new  concatenation  operator: 


RV23  : 


PN#P 0 

p  N  #  ([*.y]) 

RV25  1  FinjYY] 


RV24 

RV26 


p  N#y) 

PW# 


Y  in  [X.Y] 


4.1.4  Explicit  Interpretations 

The  following  approach  to  the  idealization  problem  maintains  the  spirit  of  the 
BAN  family  of  belief  logics,  and  fits  nicely  with  the  theory  generation  verification 
technique.  We  replace  the  informal  idealization  step  by  making  concrete-message 
interpretation  explicit  within  the  logic.  The  form  of  the  BAN-like  logics  suggests 
a  natural  expression  of  idealizations:  as  extra  rules  added  to  the  logic.1  Each 
protocol  will  have  a  set  of  interpretation  rules  that  can  be  used  by  all  principals 
to  assign  abstract  meanings  to  the  concrete  messages  they  receive.  For  instance, 
if  Alice  sees  the  signed  message  [  A .  B .  K] ,  she  might  be  allowed  to  assume  that 

the  meaning  of  that  message  is  A  B.  To  allow  this  sort  of  interpretation,  the 
protocol  could  include  this  rule: 


P  N  Q  N  tggjfl 

P^Q^pJUq 

Kailar  uses  a  similar  technique  to  assign  complex  meanings  such  as  “P  agrees 
to  sell  N  items  at  price  X"  to  messages  [Kai96].  With  these  extra  interpretation 
rules,  we  start  from  the  usual  initial  assumptions,  and  derive  all  properties  of  the 
protocol  directly  from  the  concrete  protocol  messages,  rather  than  starting  off  with 
idealized  messages. 

1If  we  took  the  approach  of  Abadi  and  TUttle  [AT91]  (and  others),  allowing  principals  to  use 
modus  ponens,  these  interpretation  rules  could  be  expressed  instead  as  formulas  held  as  initial 
assumptions.  This  is  equivalent  to  the  approach  described  here,  but  does  not  work  as  well  with 
theory  generation. 
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We  could  allow  each  protocol  to  use  any  custom  interpretation  rules  its  de¬ 
signer  (or  specifier)  chooses,  but  this  flexibility  would  make  it  impossible  to  prove 
any  meaningful  claims  about  the  results  of  RV  protocol  analyses  in  general.  In¬ 
stead  we  restrict  the  allowed  interpretation  rules  to  those  conforming  to  some 
pre-established  rule  schemata. 

To  start  with,  we  will  allow  interpretation  rules  in  any  of  die  following  forms; 

,  fNQhM  PNQNM  g„.  p<  m 

P  |=  Q  h  M'  P  |=  Q  (w  M'  P  o  M' 

Here,  M  is  a  pattern  matching  concrete  messages,  and  M'  is  a  formula  represent¬ 
ing  an  idealized  message,  which  may  include  variables  from  the  premise.  The 
first  two  forms  will  be  used  to  interpret  authenticated  messages;  since  the  recip¬ 
ient  is  certain  who  sent  the  concrete  message,  it  can  safely  use  that  information 
for  interpretation.  For  instance,  the  variable  Q  may  occur  in  M’,  in  which  case 
the  idealized  meaning  is  dependent  on  the  sender’s  identity.  The  third  form  will 
be  used  for  messages  that  have  useful  meanings  despite  having  undetermined  ori¬ 
gin.  This  situation  does  not  often  arise  in  BAN  reasoning,  but  it  does  in  RV,  in 
particular  for  the  honesty  and  secrecy  checks  introduced  later  in  this  chapter. 

We  impose  some  additional  restrictions  on  the  form  of  these  interpretation 
rules: 

11 .  In  M,  the  pattern  matching  the  concrete  message,  the  only  function  that  may 
occur  is  dot, 

12.  In  M\  the  idealized  meaning,  the  encrypt  function  must  not  occur. 

13.  In  both  M  and  M\  there  must  be  no  constants  (0-ary  functions  such  as  A  and 
S),  unless  the  value  of  those  constants  are  fixed  across  all  protocol  runs.  For 
instance,  a  server  name  $  is  permitted  in  these  arguments  only  if  S  is  the 
same  principal  in  every  run  of  the  protocol. 

14.  For  a  given  protocol,  any  given  concrete  message  must  be  able  to  match  at 
most  one  of  the  interpretation  rules.  Along  with  the  honesty  condition  de¬ 
scribed  later,  this  prevents  ambiguous  interpretations  of  concrete  messages. 

These  restrictions  on  the  form  of  interpretation  rules  help  ensure  that  the  usual 
BAN-style  inferences  remain  reasonable  regardless  of  the  interpretations  used. 
For  instance,  the  message-meaning  rules  such  as 

p^qAp  V  ]  {.VI* 

P  tee  MX, if) 
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would  make  no  sense  if  interpretations  could  arbitrarily  map  {X}^  to  {X}k2 
(in  violation  of  condition  12),  since  K2  could  be  a  shared  key  that  the  sender 
had  no  knowledge  of,  leading  the  recipient  to  draw  a  dangerous  conclusion  about 
the  origin  of  the  message.  We  discuss  further  the  reasons  for  these  restrictions 
in  Section  4.2.2,  where  we  examine  honesty  properties  in  the  context  of  these 
explicit  interpretations. 

We  need  to  extend  the  RV  notation  and  interpretation  schemata  further  to  ex¬ 
press  interpretations  required  by  some  common  protocols.  Abadi  and  Needham, 
Mao,  and  others  have  observed  that  nonces  are  used  in  cryptographic  protocols  not 
just  to  establish  freshness,  but  as  abbreviations  for  sets  of  principal  names,  keys, 
and  other  nonces  [Mao95,  AN96].  The  bindings  established  for  these  nonces  are 
specific  to  a  run  of  the  protocol,  and  we  will  see  later  that  it  is  important  to  handle 
them  explicitly  in  the  interpretation  process.  To  support  this  practice,  we  intro¬ 
duce  a  new  operator:  bind  (see  Figure  4.3).  The  statement,  N  X,  represents 


Function 

Notation 

Meaning 

bind(N,X ) 

AT~»  X 

N  stands  for  the  formula  X 

Figure  4.3:  Functions  of  RV  for  supporting  explicit  interpretations. 

the  assumption  that  nonce  N  “stands  for”  the  formula  X.  We  allow  the  interpre¬ 
tation  rule  forms  described  above  to  be  extended  to  make  use  of  bound  nonces  in 
two  ways: 

•  Interpretation  rules  of  the  forms  SI  and  S2  (interpretations  of  authenticated 
messages)  may  be  extended  with  the  following  set  of  extra  premises: 

P  |=  AW  F  Ni  in  M 

This  represents  the  “expansion”  of  a  bound  nonce  by  the  principal  who  pro¬ 
duced  that  nonce.  Note  that  it  requires  the  nonce  to  be  a  shared  secret; 
otherwise  the  recipient  cannot  safely  assume  that,  for  instance,  the  sender 
has  seen  the  correct  bind  expression. 

•  Interpretation  rules  of  the  forms  SI  and  S2  may  also  be  extended  with  the 
following  set  of  extra  premises: 

P  {=  Q  AW  F  Ni  in  M 

This  extension  allows  a  principal  to  expand  a  nonce  whose  binding  has  been 
previously  declared  by  the  sender. 
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These  extensions  can  be  applied  repeatedly,  so  a  single  interpretation  rule  may 
handle  several  nonce  bindings  simultaneously.  In  practice  this  is  rarely  necessary. 
Note  that  the  restrictions  11-14  still  apply  to  the  extended  interpretation  rules;  in 
particular  the  N{  must  be  variables. 

We  require  that  bound  nonces  be  believed  fresh  by  their  creators: 


RV27  : 


P£#(N) 


These  bindings  are  thus  limited  in  scope  to  a  single  protocol  run. 


4.1.5  Example 


The  following  example  will  illustrate  the  use  of  explicit  interpretations  for  the 
Otway-Rees  key-exchange  protocol  [OR87].  The  protocol  allows  a  server  to  dis¬ 
tribute  a  session  key,  Kab,  to  the  participating  principals  using  just  four  messages. 
These  are  the  messages  in  their  concrete  form: 


Message  1.  A—*  B  : 
Message  2.  B  — >  S  : 
Message  3.  S  —>  B  : 
Message  4.  B  — ►  A  : 


M.A.B.  [N„.M.A.B]k] 

M.A.B.  [Na.M.A.B\Kal .  [N„.M.A.B  K>> 

M.  [J .  [JV.JC*]* J 

M.  [JVa.«*]„  1 


This  protocol  is  similar  to  the  Kerberos  protocol,  but  it  uses  nonces  (Na,  Nb,  and 
M),  rather  than  timestamps,  to  ensure  freshness.  As  a  result,  its  security  does  not 
depend  on  synchronized  clocks. 

The  original  BAN  idealization  of  this  protocol  makes  use  of  a  new  nonce,  Nc, 
which  “corresponds  to”  (M,  A,  B).  We  will  use  a  more  straightforward  idealiza¬ 
tion  without  this  potentially  hazardous  informal  abbreviation: 


Message  1.  A  B  :  {Na  [M.A.B]}k.. 

Message  2.  B  -*  .S' :  {Na  {Nb  •  [M.A.B]  Uv 

Message  3.  S  -  B  ;  {N„  A  A  B}^,.{.\\.  A  B}k>, 

Message  4.  B  — »  A:  {Na,  A  B}xat 


We  have  added  bind  expressions  to  the  idealizations  of  the  first  two  messages. 
Because  they  have  told  the  server  these  bindings,  A  and  B  can  safely  (and  un¬ 
ambiguously)  interpret  the  later  messages  from  S  as  containing  shared  keys  for 
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A  and  B.  In  the  next  section,  we  will  discuss  the  precise  restrictions  on  message 
sending  and  interpretation  that  make  these  bindings  necessary. 

Now  that  we  have  a  desired  idealized  protocol,  it  remains  to  define  a  set  of 
interpretations  that  produce  these  idealized  messages  from  the  corresponding  con¬ 
crete  ones.  The  following  interpretations  suffice: 

P  |=  Q  |~  [N1.N2.R1.R2] 

P  |=  Q  |~  ^  [N2.Ri.R2] 


P^Q^[Ni.K]  P^Ni^iNi.Ri.Rz]  P  |=  P  ^  Q 
_ JVi  in  [AMT] _ 

P^Q^r  (^i> R\  " #2) 

The  first  interpretation  is  intended  to  apply  to  messages  1  and  2,  and  the  second 
to  messages  3  and  4.  To  analyze  this  protocol,  we  start  with  initial  assumptions 
similar  to  those  used  by  BAN,  with  the  following  additions: 


A  |=  Na  ^  [M.A.B]  A  |=  A  ^  S 

B^Nb^  [M.A.B]  b^B^S 


Note  that  the  nonces  Na  and  Nb  are  required  to  be  secret  in  this  formalization  of 
the  protocol,  whereas  they  were  not  in  the  BAN  formalization.  In  the  original 
BAN  analysis,  in  fact,  “optimizations”  to  the  protocol  were  suggested,  which  in¬ 
volved  sending  these  nonces  in  the  clear.  The  authors  later  realized  that  this  was 
unsafe,  but  the  BAN  logic  itself  provides  no  way  to  detect  this  problem. 

The  effect  of  sending  each  message  is  represented  by  the  receiver  seeing  the 
concrete  message: 


B< 

S< 

B< 

A< 1 


[M.A.B.  [Na.M.A.B]Kaa 

M.A.B.  \x Na.M.A.B)Z .  [Nb.M.A.B]K J 

M.  [Na.Kab\Kae .  [Nb.Kab]Kbs 

M. 


Using  the  standard  message-meaning  and  nonce- verification  rules,  we  can  derive 
from  message  4  that 


A  N  S  N  [Na.Kab\ 
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Then,  applying  the  second  interpretation  rule  with  A’s  initial  binding  and  secrecy 
assumptions  yields  the  desired  idealized  message: 

-AMN  (n^aAb) 

This  satisfies  one  of  the  authentication  goals  of  the  protocol. 

The  remainder  of  the  belief-property  derivation  for  this  protocol  proceeds  sim¬ 
ilarly  to  the  original  BAN  analysis  and  produces  similar  conclusions. 

4,2  Honesty 

Burrows,  Abadi,  and  Needham  recommend,  “for  the  sake  of  soundness,  we  al¬ 
ways  want  to  guarantee  that  each  principal  believes  the  formulas  that  he  gener¬ 
ates  as  messages”  [BAN9Q].  This  requirement  has  intuitive  appeal:  the  protocol 
should  not  require  principals  to  “lie.”  If  legitimate  participants  were  free  to  send 
arbitrary  messages,  recipients  could  derive  faulty  conclusions  about  the  senders’ 
beliefs  from  those  messages.  We  will  refer  to  this  kind  of  restriction  as  an  honesty 
property.  Without  honesty  there  is  little  hope  of  demonstrating  that  derived  beliefs 
are  always  sound  with  respect  to  some  reasonable  model.  In  the  next  two  sections, 
we  discuss  honesty  first  for  idealized  protocols,  and  then  in  the  context  of  explicit 
interpretations. 

4.2.1  Honesty  in  Idealized  Protocols 

We  need  a  more  precise  statement  of  the  honesty  property.  The  primary  goal  is 
to  prevent  message  recipients  from  deducing  beliefs  of  other  principals  that  are 
invalid,2  Later  we  will  want  to  prevent  other  sorts  of  misinterpretations  as  well. 
To  achieve  this,  we  must  consider  the  circumstances  under  which  one  principal 
can  decide  another  principal  holds  some  belief.  This  typically  happens  through 
the  application  of  a  message-meaning  rule,  such  as  the  rule  for  interpreting  mes¬ 
sages  signed  with  a  shared  key,  followed  by  the  application  of  a  nonce- verification 
rule.  We  focus  on  the  message-meaning  step:  any  message  (formula)  that  is  en¬ 
crypted  under  some  key  (e.g.,  {A  ^  B}kb),  or  combined  with  some  secret 

2Strictly  speaking,  principals  do  not  deduce  one  another’s  beliefs  in  the  RV  logic;  they  only 
deduce  that  another  principal  recently  made  some  statement  (P  Q  |w  X).  However,  the  effect 
is  the  same  as  in  BAN,  where  P  ^  Q  ^  X  can  be  derived. 
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(e.g.,  {A  B)Na)  could  potentially  be  interpreted  as  a  belief  of  the  principal  do¬ 
ing  the  encrypting  or  combining.  Therefore,  we  will  state  the  honesty  property  in 
terms  of  messages  signed,  where  a  principal  signs  a  message  whenever  it  applies 
encryption  or  secret-combination  to  that  message.  (Note  that  this  notion  is  broader 
than  that  of  public-key  digital  signatures.)  A  principal  must  take  responsibility  for 
any  statement  it  signs,  since  those  are  the  statements  that  might  later  be  used  by 
other  principals  to  derive  beliefs  of  the  signer. 

We  can  now  state  the  honesty  property: 

Honesty  property  (for  idealized  protocols):  For  every  message  com- 
-■  i  ponent  M  that  a  principal  P  signs,  it  must  be  true  that  P  believes  M 

at  the  point  at  which  P  sent  the  message  containing  M. 

The  requirement  that  the  belief  hold  at  the  time  the  message  is  sent  prevents  cir¬ 
cular  situations  in  which  two  (or  more)  principals  send  each  other  statements  that 
neither  believes  initially,  but  that  both  come  to  believe  after  receiving  the  other’s 
message. 

Most  of  the  idealized  protocols  in  the  published  BAN  analyses  will  not  pass 
this  test,  since  they  typically  contain  messages  like  {Ta,  A  < — >  B}xab,  where  the 
signer  does  not  actually  “believe”  Ta.  We  can  fix  this  by  replacing  each  trouble¬ 
some  message  fragment,  X,  with  some  formula  the  sender  actually  believes,  such 
as  A  sees  X  or  fresh(X).  This  approach  requires  introducing  some  extra  “seeing” 
rules,  such  as,  P  sees  Q  said  X  b  P  sees  X. 

4.2.2  Honesty  with  Explicit  Interpretations 

The  honesty  property  is  fairly  simple  in  the  context  of  reasoning  about  idealized 
protocols,  but  when  we  introduce  interpretation  rules,  it  becomes  more  interesting. 
Since  concrete  messages  have  no  direct  meaning,  it  no  longer  makes  sense  to  talk 
about  believing  the  contents  of  a  message;  we  can  only  discuss  believing  some 
interpretation  of  a  message.  Roughly,  we  want  to  extend  the  honesty  property  to 
say  that,  for  every  message  component  a  principal  signs,  that  principal  must  be¬ 
lieve  all  possible  interpretations  of  that  message  component.  This  allows  honesty 
to  proscribe  both  blatant  lies  and  statements  open  to  misinterpretation.  We  must, 
however,  refine  the  notion  of  interpretation  for  this  definition  to  be  useful. 

By  making  interpretations  explicit,  we  expose  the  possibility  that  a  single  con¬ 
crete  message  may  be  interpreted  differently  in  different  runs  of  the  protocol.  This 
would  make  the  honesty  property  difficult  to  verify;  we  would  prefer  to  confine 
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our  reasoning  to  a  single  run,  Taut  have  the  results  hold  in  the  presence  of  multiple 
runs.  By  imposing  restrictions  11—14  (Section  4.1.4)  on  the  interpretations,  we  can 
ensure  that  no  additional  interpretations  are  possible  in  other  runs  of  the  protocol. 
For  instance,  restriction  13  requires  that  interpretation  rules  make  no  mention  of 
constants  whose  values  are  specific  to  a  run  of  the  protocol.  This  guarantees  that 
the  result  of  applying  an  interpretation  to  a  given  concrete  message  will  not  de¬ 
pend  on  the  protocol  run  in  which  the  interpretation  is  applied.  This  restriction, 
which  corresponds  loosely  to  Abadi  and  Needham’s  “explicitness”  principle,  is 
actually  stronger  than  necessary,  but  in  combination  with  the  bind  operator  intro¬ 
duced  in  Section  4.1,  it  seems  to  be  flexible  enough  to  handle  most  protocols,  and 
it  substantially  simplifies  verification. 

We  model  encryption  explicitly  at  the  concrete  level,  so  there  is  no  need  for  in¬ 
terpretations  to  introduce  encryption.  To  preserve  orthogonality  with  the  message¬ 
meaning  rules,  interpretations  should  also  not  perform  decryption.  This  is  en¬ 
forced  through  the  simple  syntactic  restrictions  II  and  12,  which  disallow  encryp¬ 
tion  operators  on  either  side  of  an  interpretation.  Now,  since  secret-combination  is 
only  useful  within  encrypted  messages  and  encryption  is  unaffected  by  interpreta¬ 
tion,  we  can  express  honesty  as  a  (conservative)  restriction  on  concrete  messages 
that  a  principal  encrypts. 

The  honesty  property  for  the  explicit  interpretations  case  is  as  follows: 

Honesty  property  (with  explicit  interpretations):  For  every  message 
M  that  a  principal  P  encrypts,  and  for  every  possible  interpretation, 

M',  of  M,  it  must  be  the  case  that  P  believes  M'  at  the  point  at  which 
P  sent  M. 

It  remains  to  define  what  a  possible  interpretation  is  in  this  context.  The  honesty 
property  should  be  a  function  of  the  sender’s  beliefs  and  the  global  interpretations, 
so  an  interpretation  M*  of  M  will  be  considered  possible  if  P  cannot  determine 
it  is  impossible.  This  means  that,  in  principle,  P  must  consider  all  possible  recip¬ 
ients  of  the  message  at  all  times,  with  any  conceivable  set  of  beliefs.  It  is  difficult 
in  a  belief-logic  setting  to  reason  about  such  a  broad  set  of  possibilities,  but  fortu¬ 
nately  we  get  some  help  from  the  notions  of  shared  and  public  keys,  secrets,  and 

freshness.  For  instance,  if  a  principal  A  believes  A  B  then  she  implicitly 
believes  that  there  is  no  C  who  currently  believes  C  D  where  C,D  ±  A,  B, 
and  that  any  C  who  holds  such  a  belief  in  the  future  will  not  consider  this  message 
fresh. 

Together  with  the  syntactic  restrictions  on  interpretation  rules,  the  honesty 
property  provides  many  of  the  guarantees  we  would  like  to  hold  for  idealizations. 
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The  14  restriction  provides  a  further  guarantee  that  simplifies  honesty  checking 
via  theory  generation:  at  most  one  of  the  interpretation  rules  for  a  protocol  will 
match  any  given  concrete  message. 


Function 

Notation 

Meaning 

legit  (M) 

legit(M) 

M  is  a  legitimate  message  to 
send,  according  to  the  honesty 
property 

signed  (M,  Ms,  P,  Q) 

signed(M,  Ma ,  P,  Q) 

Ms  is  a  signed  message  for  P 
from  Q 

Figure  4.4:  Functions  of  RV  for  supporting  honesty. 

To  reason  about  honesty  within  RV,  we  introduce  two  new  functions  (Fig¬ 
ure  4.4):  legit,  indicating  that  a  message  is  safe  to  transmit  from  an  honesty  per¬ 
spective,  and  signed,  describing  situations  where  a  principal  may  be  held  respon¬ 
sible  for  a  transmitted  message. 

To  derive  legit,  we  introduce  rules  that  are  complementary  to  the  interpretation 
rules  for  the  protocol.  An  interpretation  rule  specifies  what  meaning  a  receiver 
may  safely  assign  to  a  concrete  message;  a  legit  rule  specifies  a  concrete  message 
whose  meaning  is  certain  to  be  believed  by  the  sender.  For  each  interpretation  rule 
of  the  form  Si  or  S2,  we  add  a  rule  of  the  following  form,  with  the  same  M  and 
M': 

S1//S2/ .  Q\=M'  Q  |=  signed(M,  M8 ,  P,  Q) 

Q  |=  legit  (Ms) 

This  means  that  if  the  message  has  an  interpretation  that  the  sender  believes,  then 
a  signed  version  of  that  message  is  safe  to  transmit.  Similarly,  if  a  message  can  be 
given  an  “anonymous  interpretation”  that  the  sender  believes,  it  can  be  sent.  We 
therefore  add  a  rule  of  the  following  form  for  each  S3  rule: 

S3'  • 

'  Q  (ee  legit(M) 

To  account  for  bound  nonces,  we  must  extend  Sl'/S2'  rules  in  ways  analogous  to 
the  two  allowed  extensions  of  S1/S2  interpretations.  For  bound-nonce  extensions 
of  the  first  kind,  we  add  the  following  premises: 

Q<]N~~>F  QcP^Q  N  inM 
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For  bound-nonce  extensions  of  the  second  kind,  we  add  these  premises: 

Q|=jV^F  N  inM 


We  then  need  rules  for  determining  when  a  message  is  believed  to  be  signed: 

RV28  •  QNP 

'  Q  |ee signed) A/, {M}K,P,Q) 


Ry,0  .  Q  K  =  K 

Q  |=  signed  (A/,  {Af}^  ,  P .  Q) 

RV30  •  YmM 

'  Q  |e  signed(M,  {M} K,P,Q ) 

Finally,  we  introduce  two  message  transformations  that  preserve  “legitimacy,”  for 
the  purpose  of  producing  compound  messages: 


RV31  •  QMegit(X)  QNfe  gttQO 

■  '  g  N  legit([XF]) 


RV32  : 


Q  f=  legit(X) 

Q  N  leg*t({X}^-) 


4,2.3  Example 

At  several  steps  in  this  development,  we  have  imposed  restrictions  that  were 
stronger  than  necessary  for  soundness.  We  will  demonstrate  here  that  a  practical 
protocol  can  still  pass  these  tests.  The  Needham-Schroeder  public-key  protocol 
illustrates  the  trouble  principals  can  get  into  if  they  are  not  bound  by  honesty.  The 
full  protocol  involves  seven  messages,  but  four  of  these  (messages  1,  2,  4,  and  5) 
are  concerned  only  with  requesting  and  issuing  public-key  certificates  for  A  and 
B.  We  focus  on  the  three  messages  exchanged  between  A  and  B  here: 

Message  3.  A  — ►  B  :  {[A^.A]}^ 

Message  6.  B  -+  A:  {[-/Va.JVj,]}^ 

Message  7,  A  -+  B  ;  {Nb}Kb 
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In  the  omitted  messages  of  this  protocol  (1, 2, 4,  and  5),  A  and  B  get  each  other’s 
public  keys  from  a  trusted  server.  The  three  messages  shown  above  are  a  simple 
exchange  of  the  secrets  Na  and  Nb,  in  which  each  message  is  encrypted  with  the 
recipient’s  public  key.  The  presence  of  Na  in  Message  6  and  Nb  in  Message  7  is 
intended  to  acknowledge  the  successful  receipt  of  those  secrets. 

The  idealized  form  of  these  messages  given  in  the  BAN  analysis  is  equivalent 
to  the  following: 

Message  3.  A  —>  B  :  {Na}Kb 

Message  6.  B  — »  A  :  j  ^ A  ^  B ,  Na'j  j 

Message  7.  A  -»  B  :  ^  B,B  |=  A  ^  s)  ,AT6)}^ 

A  and  B  hold  the  following  initial  assumptions: 


A^#(iV0)  B^f{Nb) 

A\=A^B  B^A^B 

B^e&B 

A)=&  B  B\=&A 


In  constructing  interpretation  rules  to  match  the  idealization  above,  we  would  first 
run  into  trouble  because  Messages  3  and  6  have  the  same  structure  (two  fields). 
We  can  handle  this  if  we  assume  principals  and  nonces  are  distinguishable,  by 
applying  the  automatic  tagging  approach  mentioned  above. 

A  more  interesting  problem  arises,  however,  when  we  look  at  the  interpreta¬ 
tion  required  for  Message  6.  The  following  rule  appears  to  produce  the  desired 
idealization: 

A^jBjv  [JVj.iVa] 

A  N  B  b  ^  B,  N^j 

Certainly  A  can  determine  that  the  concrete  Message  6  came  from  B,  since  it 
contains  the  secret  Na,  and  thus  the  interpretation  succeeds.  However,  when  we 
apply  the  honesty  check  to  B,  we  find  that  B  cannot  be  certain  that  Na  is  a  secret 
shared  by  A  and  B,  since  it  has  no  authenticated  message  from  A  to  that  effect. 
Thus,  B  fails  the  honesty  check  for  Message  6. 

This  honesty  failure  corresponds  to  the  attack  discovered  by  Lowe  [Low95]. 
In  this  man-in-the-middle  attack,  an  intruder  participates  in  two  concurrent  runs 
of  the  protocol.  In  one  run,  the  intruder  conducts  a  legitimate  transaction  with 
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A,  using  his  true  identity,  while  in  the  other  run,  he  successfully  masquerades  as 
A  to  another  principal,  B.  The  honesty  property  and  interpretation  restrictions 
allow  us  to  protect  against  such  multiple-run  attacks  without  explicitly  represent¬ 
ing  separate  protocol  runs.  Multiple-run  attacks  typically  rely  on  messages  being 
misinterpreted  when  they  are  received  in  a  different  context  (run)  than  the  one  in 
which  they  were  produced.  Millen  has  proven  that  some  protocols  are  vulnerable 
to  parallel  attacks  (those  involving  concurrent  runs  in  which  the  same  principal 
plays  the  same  role  in  different  runs),  despite  being  secure  against  all  non-parallel 
attacks  [Mil99].  The  RV  interpretation  restrictions  ensure  that  each  message  is 
interpreted  consistently  regardless  of  which  run  of  the  protocol  it  appears  in,  and 
thus  the  honesty  properties  derived  apply  across  all  protocol  runs. 


4.3  Secrecy 

Critics  of  belief  logics  often  note  that  the  logics  do  not  address  secrecy  properties. 
It  was  observed  very  early  that  BAN  reports  no  problems  with  a  protocol  in  which 
secret  keys  are  transmitted  in  the  clear  [Nes90].  Indeed,  traditional  BAN  anal¬ 
ysis  omits  plaintext  parts  of  messages  from  consideration  since  they  “contribute 
nothing  to  the  meaning  of  the  protocol.” 

BAN  adherents  sometimes  assume  that  this  shortcoming  is  easily  overcome 
since  one  can  determine  by  inspection  whether  sensitive  data  is  sent  in  the  clear 
or  to  untrusted  parties.  However,  this  argument  ignores  the  subtle  part  of  secrecy 
properties:  determining  exactly  what  things  must  be  kept  secret,  and  from  whom. 
The  Needham-Schroeder  public  key  flaw  Lowe  discovered  is  fundamentally  a  se¬ 
crecy  flaw:  A  reveals  a  secret,  Ns,  to  B  without  being  certain  that  B  is  allowed  to 
know  it.  This  flaw  remained  undiscovered  for  over  fifteen  years,  suggesting  that 
secrecy  can  be  just  as  subtle  as  authentication. 

4.3.1  Formalization 


Function 

Notation 

Meaning 

maysee(P,  X) 

I 

P  maysee  X 

I 

P  is  allowed  to  see  X 
an  intruder 

Figure  4.5:  Functions  of  RV  for  supporting  secrecy  checks. 
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The  class  responsibility  properties  includes  both  the  honesty  properties  discussed 
earlier  and  secrecy  properties.  These  are  properties  that  require  principals  to  avoid 
revealing  information  that  may  be  secret. 

like  honesty,  secrecy  can  be  formalized  within  the  belief-logic  context  in  a 
way  that  is  amenable  to  theory  generation.  Central  to  this  formalization  of  se¬ 
crecy  is  the  notion  that  a  principal  P  may  see  (is  allowed  to  see)  some  message 
X.  We  introduce  a  new  operator  to  reflect  this:  P  maysee  X.  For  instance,  if 
A  and  B  share  a  key  Kab,  they  will  both  normally  believe  A  maysee  Ka\,  and 
B  maysee  Kab .  We  will  also  introduce  a  special  principal,  /,  corresponding  to  an 
intruder,  and  consider  maysee(I,  X)  as  equivalent  to  VP  P  maysee  X.  Principals 
may  derive  maysee  by  applying  any  of  several  new  rules: 


RV33  : 


P  ^  Q  maysee  K 


RV34  : 


P<]Q^P 
P  ^  Q  maysee  Y 


RV35 


P<  &Q 


Ki  =  K~2 


-l 


P  ^  Q  maysee  K2 


RV36 


RV38 


P  <1  (Q  maysee  F) 
P  ^  Q  maysee  Y 
P  maysee  X 
P  maysee  {X}K 


RV3T  : 


P<(Q<Y) 


P)=Q  maysee  Y 

RV39 :  f-Ngmay**  {X  Y) 
P^Q  maysee  X 


RV40  : 


P  ^  Q  maysee  X  P  maysee  Y 


RV41 


P  ^  Q  maysee  [X.Y] 
P  ^  /  maysee  X 


'  P  maysee  X 

We  further  introduce  four  rules  for  determining  what  messages  may  safely  be  seen 
by  an  intruder: 


RV42 


p« 


'  P  I  maysee  K 


P  N  Q maysee X  P\^&Q 
P  f=  /maysee  {X}K 

P  ^  Q  maysee  X  P  j=  R  maysee  X  P  R 

P  ^  /maysee  {X}K 

Given  these  definitions,  the  secrecy  property  can  be  expressed  quite  simply: 
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Secrecy  property:  For  every  message  M  that  a  principal  P  sends,  P 
believes  maysee(I,  M)  at  the  point  at  which  P  sent  M. 

The  rules  above  for  deriving  maysee  are  conservative.  For  instance,  it  would  be 
safe  for  a  principal  to  derive  maysee(I ,  X)  if  it  sees  X  unencrypted,  This  would 
require  introducing  a  new  operator  similar  to  sees,  and  some  corresponding  rules. 
In  practice,  it  seems  that  these  additions  are  not  necessary. 

4.3.2  Example 

We  can  illustrate  secrecy  too  in  the  context  of  the  Needham-Schroeder  public  key 
protocol: 

Message  3.  A  — >•  B  :  {[A/q.A]}^ 

Message  6.  B  — ►  A:  {[JVfl  JVb]}^ 

Message  7,  A-+  B  ;  {iV*}^ 

Suppose  that,  in  an  attempt  to  repair  the  honesty  failure  observed  in  Section  4.2.3, 
we  give  Message  6  a  more  conservative  interpretation: 

A  <  [JViJVa] 

A<(N2,Ni) 

With  this  interpretation,  A  does  not  need  to  believe  that  B  was  the  sender  in  order 
to  interpret  the  message,  but  interpretation  restriction  13  (from  Section  4.1.4)  also 
prevents  A  from  concluding  anything  about  B.  In  particular,  A  cannot  decide 
from  this  message  that  N2  is  a  secret  between  A  and  B. 

As  a  result  of  this  lack  of  information,  A  will  run  afoul  of  the  secrecy  check 
in  sending  Message  7.  In  order  for  A  to  safely  send  the  message  ,  secrecy 

requires  that  we  can  derive 


A  ^  B  maysee  JV& . 

Since  A  does  not  know  the  origin  of  Message  6,  it  cannot  be  sure  that  it  is  safe  to 
reveal  iV&  to  B,  so  secrecy  is  violated. 

In  Chapter  5,  we  present  a  variety  of  examples  in  which  the  RV  logic  is  applied 
to  both  correct  and  incorrect  protocols. 
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4.4  Feasibility 

Since  the  RV  logic  represents  protocols  at  a  concrete  level,  it  is  well  suited  to  ex¬ 
pressing  what  we  call  feasibility  properties.  This  is  a  class  of  simple  properties 
that  represent  the  ability  of  the  parties  in  a  protocol  to  carry  out  their  assigned 
roles.  In  order  for  a  protocol  to  be  feasible,  it  must  be  guaranteed  at  each  step 
that  the  party  who  is  to  send  the  next  message  knows  all  the  information  required 
to  produce  that  message.  This  may  involve  decrypting  and  disassembling  ear¬ 
lier  messages  it  has  received,  and  constructing  and  encrypting  the  new  message. 
Checking  these  properties  does  not  tend  to  reveal  subtle  protocol  flaws,  but  is 
rather  a  simple  sanity  check  that  is  useful  for  early  detection  of  mistakes  in  the 
protocol  specification. 


Function 

Notation 

Meaning 

can.produce(P,  X) 

P  canProduce  X 

P  can  generate  the  message  X 

Figure  4.6:  Function  of  RV  for  supporting  feasibility  checks. 


The  rules  for  deriving  can. produce  are  straightforward.  A  principal  can  pro¬ 
duce  any  message  (or  message  fragment)  it  has  seen: 


RV45  : 


P  canProduce  M 


A  principal  can  concatenate  messages  it  can  produce: 


RV46  : 


P  canProduce  X  P  canProduce  Y 
P  canProduce  X.Y 


Finally,  a  principal  can  encrypt  a  message  using  a  key  it  can  produce: 

r P  canProduce  X  P  canProduce  K 

RV47  i  _ _ _ 

P  canProduce  {X}K 


To  check  feasibility  for  a  protocol,  we  verify  for  each  message  M*  to  be  sent  by 
Pit  that  the  protocol  prefix  {M0, . . . ,  Mi- 1}  implies 


Pi  canProduce  M* . 

Chapter  5  contains  an  example  feasibility  check. 
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4.5  Summary 

We  have  now  presented  the  full  RV  logic,  which  provides  the  following  significant 
features: 

•  It  provides  explicit  interpretations,  through  which  a  protocol  can  be  speci¬ 
fied  at  a  concrete  level  and  reasoned  about  using  abstract  belief  constructs, 
A  set  of  interpretation  restrictions  serves  to  prevent  various  kinds  of  flawed 
or  hazardous  interpretations. 

•  It  expresses  traditional  belief  properties,  with  added  confidence  due  to  the 
formal  interpretation  step. 

•  It  expresses  honesty  properties,  which  assert  that  principals  participating 
in  a  protocol  are  not  required  to  send  any  messages  whose  interpretations 
they  do  not  believe.  In  conjunction  with  the  interpretation  restrictions,  this 
catches  some  protocol  flaws  resulting  from  insufficiently  precise  messages. 

•  It  expresses  secrecy  properties,  which  show  that  a  protocol  does  not  require 
its  participants  to  transmit  any  information  that  might  be  a  secret.  This 
check  is  performed  through  the  positive,  monotonic  derivation  of  maysee 
properties,  rather  than  by  proving  the  absence  of  secret  leaks, 

•  It  expresses  feasibility  properties,  which  ensure  that  each  participant  in  a 
protocol  is  capable  of  constructing  the  messages  it  is  require  to  transmit, 

In  the  next  chapter,  we  explore  the  practical  use  of  RV  in  protocol  verification 
with  theory  generation. 
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Chapter  5 


Theory  Generation  for  RY 


In  this  chapter  we  describe  the  practical  application  of  the  theory  generation  ap¬ 
proach  to  the  RV  logic  described  in  Chapter  4.  We  explain  a  general  step-by-step 
procedure  for  analyzing  a  protocol  in  RV  using  theory  generation,  and  then  work 
through  several  protocol  analyses  in  the  context  of  RV.  The  focus  here  is  on  hon¬ 
esty  and  secrecy  properties,  since  the  examples  in  Chapter  3  addressed  traditional 
belief  properties  for  BAN,  AUTLOG,  and  Kailar’s  logic  of  accountability. 


5.1  Technique 

To  apply  theory  generation  with  the  RV  logic,  we  must  first  express  the  protocol 
under  examination  in  a  form  suitable  as  input  to  TG*.  A  protocol  specification  in 
RV  has  five  parts: 

•  The  sequence  of  concrete  messages,  Mi...  Mn,  and  their  respective  senders 
and  receivers,  si . . .  sn  and  n . . .  r„.  In  contrast  to  the  BAN  approach,  it  is 
important  to  specify  the  sender  as  well  as  the  receiver  of  each  message, 
so  that  the  responsibility  of  senders  and  the  protocol’s  feasibility  can  be 
checked. 

•  The  initial  assumptions  held  by  each  principal.  As  in  BAN,  these  typically 
include  assumptions  of  freshness,  jurisdiction,  shared  secrets,  and  keys  and 
their  functions.  In  addition,  RV  specifications  may  contain  maysee,  public, 
and  bind  assumptions, 

•  The  set  of  added  interpretation  rules  required  by  the  protocol. 
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•  The  belief  goals  of  the  protocol,  that  is,  the  beliefs  each  principal  is  expected 
to  hold  after  a  successful  run.  A  whole  class  of  protocols  may  share  similar 
belief  goals. 

•  The  set  of  constants  whose  values  are  fixed  across  all  runs  of  the  protocol. 
(Often  this  set  is  empty,  but  in  some  cases  the  identity  of  a  trusted  server, 
for  instance,  may  be  fixed.) 

When  analyzing  an  existing  protocol,  one  can  usually  determine  the  concrete  mes¬ 
sages  sent  and  received  easily.  The  appropriate  belief  goals  may  be  somewhat  less 
obvious,  but  they  are  normally  shared  by  similar  protocols.  The  most  challeng¬ 
ing  parts  of  the  specification  for  the  human  to  produce  are  the  initial  assumptions 
and  the  added  interpretation  rules.  The  process  of  generating  these  corresponds  to 
constructing  a  BAN-like  idealization,  so  it  is  not  surprising  that  it  requires  some 
ingenuity.  With  RV,  however,  mistakes  at  this  step  will  normally  lead  to  verifi¬ 
cation  failures  (and  revision  of  the  interpretations),  rather  than  to  a  silently  faulty 
analysis. 

Given  an  RV  specification  in  the  form  above,  we  must  first  check  that  the 
provided  interpretation  rules  meet  the  conditions  described  in  Section  4.1.4;  they 
must  each  be  of  the  form  SI,  S2,  or  S3,  and  satisfy  restrictions  11-14.  These 
conditions  can  be  verified  mechanically. 

Next,  we  can  use  theory  generation,  with  the  RV  rules  and  the  additional  inter¬ 
pretation  rules,  to  produce  representations  of  the  protocol  state  at  each  step.  First, 
we  run  the  TG^  algorithm  with  only  the  initial  assumptions  as  input,  producing  a 
theory  representation,  P0.  Then,  we  add  a  formula  representing  the  receipt  of  the 
first  message: 

r\  <  M\ 

Running  TGf  on  the  theory  representation,  P0,  and  this  additional  formula  will 
produce  Pi ,  representing  the  state  of  the  protocol  after  the  first  message  is  sent.  We 
then  generate  P2 . . .  Pn  in  the  same  way.  In  Chapter  6,  we  discuss  an  optimization 
for  doing  such  incremental  theory  generation  efficiently. 

With  these  P{  protocol  states  in  hand,  we  can  use  the  decision  procedure  from 
Chapter  2  to  verify  the  honesty  properties  quickly.  For  each  i  <n,  we  verify  that 
Pi  entails  the  corresponding  honesty  property: 

*»+i  N!egit(Mi+1) 

When  an  honesty  test  fails,  the  first  thing  to  check  is  whether 

«<+ 1  N  MUi 
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holds,  where  M-+1  is  the  intended  idealized  meaning  of  M%+\.  If  this  belief  does 
not  hold,  the  real  problem  likely  lies  earlier  in  the  protocol;  if  it  does  hold,  the 
interpretation  used  for  this  message  may  be  faulty. 

After  checking  honesty,  we  can  proceed  to  secrecy.  We  use  the  decision  pro¬ 
cedure  again  to  check  that  for  each  i  <  n,  Pi  entails  the  corresponding  secrecy 
property: 

^i+1  N  public(Mi+1) 

If  a  secrecy  check  fails,  examining  the  set  of  formulas  in  P*  of  the  forms 

si+i  |ee  public(JY) 
si+1  |ee  P  maysee  X 

may  suggest  the  problem. 

Next,  we  can  check  feasibility  properties  for  the  protocol,  in  a  similar  manner. 
For  each  i  <  n,  we  use  the  decision  procedure  to  check  that  Pi  entails 

Si+ 1  canProduce  Mi+X 

When  a  feasibility  check  fails,  the  problem  may  be  that  part  of  the  concrete  pro¬ 
tocol  has  been  omitted  in  the  specification.  Checking  Pj  for  formulas  of  the  form 

Si+i  *^3  X. 

should  indicate  which  key,  nonce,  or  name  the  sender  cannot  produce. 

Finally,  we  can  check  Pn  for  the  stated  belief  goals  of  the  protocol,  as  in  the 
examples  in  Chapter  3,  and  perform  any  further  desired  analyses,  such  as  tracing 
the  development  of  beliefs  held  by  a  participant  as  the  protocol  progresses. 


5.2  Applications 

To  illustrate  the  practical  use  of  both  the  theory  generation  technique  and  the  RV 
logic,  we  now  explore  three  published  authentication  protocols  using  these  tools. 
The  highlights  of  these  analyses  are  presented  below. 

5.2.1  Denning-Sacco  Public-key  Protocol 

The  Denning-Sacco  protocol  allows  A  to  generate  a  shared  key  for  communication 
with  B,  and  to  securely  hand  that  key  to  B,  where  a  server,  S,  provides  trusted 
public-key  certificates  for  A  and  B.  The  concrete  messages  are  exchanged  as 
follows: 
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Mi.  A—>S'.  [A.B] 

M2.  S^A:  {[B.Kh.Ta)}K,.{[A.Ka.Ta)}K, 

M3.  A^B:  [{{Kab.Ta]}K,  .  {[B.Kb.Ta)}K, .  {[A.Ka.Ta]}  K, 

In  the  first  message,  A  gives  the  server  ( S )  a  hint  as  to  what  public-key  certificates 
it  needs.  S  responds  with  timestamped,  signed  certificates  giving  A’s  and  B’s 
public  keys.  In  the  third  message,  A  sends  both  certificates  to  B,  along  with 
a  signed  and  timestamped  message  containing  a  shared  key,  Kab,  which  A  has 
generated.  The  following  initial  assumptions  are  fairly  routine: 


A  £&A 
Bj=&B 
S'p&A 
S\=&S 
S\=#(Ta) 

A  ^  £  controls  £*  B 

Ka  -  K'-1 
Ka  =  K>~1 


A\ee& S  " 

B\=&S 
S  |=  &  B 

a\=aAb 

A\=#{Ta) 

B  ^  S  controls  &  A 

Kb  =  K'b~ 1 


The  following,  however,  are  somewhat  unusual: 

B  ^  A  controls  A  B  A  ^  #  ( T„ ) 

These  assumptions  assert  that  B  trusts  A  to  generate  shared  keys  for  the  two  of 
them,  and  that  A  and  B  believe  that  A  and  S’s  timestamps  are  fresh  (and  thus  that 
their  clocks  are  reasonably  synchronized). 

The  participants  in  this  protocol  must  be  able  to  interpret  signed  public-key 
certificates,  and  B  must  be  able  to  interpret  the  signed  message  in  which  A  sends 
their  shared  key.  To  accomplish  this,  we  propose  the  following  two  interpretation 
rules* 

P  N  Q  N  [RJCT]  P  M  Q  N  [K.T\ 

As  in  most  key  exchange  protocols,  at  the  end  of  the  protocol,  we  want  A 
and  B  to  both  believe  they  have  a  good  shared  key,  Kab,  and  if  possible,  we  want 
them  each  to  believe  that  the  other  claims  this  key  to  be  good.  This  gives  us  the 
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following  standard  belief  goals: 

A^aJ^B  a\=b^aAb 

B^A^B  B^A^A^B 

To  complete  the  RV  specification  of  this  protocol,  we  will  assume  no  constants 
need  be  fixed  across  protocol  runs. 

We  now  proceed  with  the  protocol  analysis.  First,  we  note  that  the  inter¬ 
pretation  rules  are  both  of  the  form  S2,  and  both  satisfy  conditions  11-14,  so 
they  are  acceptable,  and  we  can  generate  the  incremental  protocol-state  theories 
Po,Pi,P2,P3.  We  are  now  ready  to  attempt  the  honesty  check. 

For  message  Mi,  the  honesty  check  is  trivial,  since  unencrypted  messages  are 
always  believed  legitimate.  For  message  M2,  we  use  the  decision  procedure  to 
verify  that 

s  N  l=git(  [{{B.Kb.T,]}K, .  {[AA..T,]}*,] ) 

follows  from  Pi.  The  derivation  of  this  result  follows  from  the  fact  that  S  believes 
Ka  is  its  public  key,  and  that  the  interpretation  of  that  message  is  independent  of 
its  recipient. 

For  message  M3,  the  honesty  check  fails.  A  quick  examination  of  the  gener¬ 
ated  theory  P2  reveals  that 

A  |ee  legit( { [Kab.Ta] }K^ ) 

does  not  hold.  The  reason  is  that  A  believes  this  message  is  signed  for  any  recip¬ 
ient  (not  just  B),  yet  the  (only)  available  interpretation  for  the  message  depends 
on  the  recipient.  This  failure  corresponds  to  a  genuine  flaw  in  the  protocol,  noted 
by  Abadi  and  Needham  [AN96],  Since  A  cannot  be  certain  who  will  interpret  this 
message,  B  could  replay  it  in  another  run  of  the  protocol,  and  thus  impersonate 
A.  The  fix  suggested  by  Abadi  and  Needham  is  to  replace  message  M3  with  the 
more  explicit 

M3.  A—>B:  [{[A.B.Kab.TQ]}K,  .  {[B.Kb.Ts]}K, .  {[A.Ka.Te]} 

With  this  version  of  the  protocol,  we  can  replace  the  two  interpretations  used 
above  with  the  following  receiver-independent  interpretation,  which  allows  the 
honesty  check  to  succeed: 

PNQN  [QJIKjT} 
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With  the  corrected  protocol,  we  can  run  the  secrecy  checks,  and  find  that  they  all 
pass: 


P0  A  ^  public( 
Pi  h  S  ^  public( 
P2  H  A  ^  public( 


\A-B]) 

{\B.Kb.T.})K,.{\A.K.T,}}K^) 
(\A.B.Kab.T,x\}K,  .  {[B.Kb.T,})K, 


.{{A.K.T.]}k,\) 


The  only  nontrivial  secrecy  check  is  for  M3,  in  which  A  transmits  Kab.  Since  it  is 
encrypted  under  Kb,  and 


P-2  \-  A  B  maysee  Kab 
P2  b  A  |ee  &  £ 

it  follows  that  A  beheves  M3  to  be  public. 

The  feasibility  property  and  belief  goals  follow  straightforwardly,  with  the 
exception  of  the  third  belief  goal, 

A  \=B  ^  A£±>B 

which  cannot  hold  since  A  never  receives  a  message  from  B.  Despite  the  fact  that 
A  cannot  be  sure  B  knows  or  believes  in  the  shared  key,  the  other  three  standard 
belief  goals  have  been  met,  so  the  protocol  has  accomplished  something.  Second- 
order  beliefs  of  this  sort  are  unnecessary  in  some  contexts,  and  by  sacrificing  them 
we  can  often  reduce  the  number  of  messages  that  must  be  sent.  This  limitation 
should  always  be  kept  in  mind,  however,  particularly  when  the  protocol’s  context 
changes. 


5.2.2  Neuman-Stubblebine  Shared-key  Protocol 

The  Neuman-Stubblebine  protocol  allows  mutual  authentication  of  two  parties  (A 
and  B)  in  four  messages,  using  shared  keys  and  without  relying  on  synchronized 
clocks  [NS93].  Each  participant  shares  a  long-term  key  with  the  trusted  server, 
which  generates  and  distributes  a  session  key  for  each  run  of  the  protocol. 

The  protocol  consists  of  the  following  four  concrete  messages: 


Mi. 

M2. 

m3. 


A-+B\ 

B^S: 

S  A: 


A. N„] 

B. Nb.{{A.K.Tb]}Kt  J 

.  {[A.KM.Tb]}Ku  ,Nb] 
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M*.  A—-B:  \{[A.Kab.Tb)}Kti .  {Ni}^ 

In  message  Mj.,  A  sends  B  an  unauthenticated  hint  that  it  would  like  to  initiate  a 
session,  where  A  identifies  that  session  by  the  nonce  Na.  B  then  sends  the  server 
(S)  a  message  containing  B’s  name,  the  nonce,  Nb,  by  which  B  identifies  this 
session,  and  a  final  encrypted  fragment  containing  A’s  name  and  nonce  as  well 
as  a  timestamp  (T&).  In  the  third  message,  S  sends  three  fragments  directly  to 
A:  an  encrypted  message  for  A  containing  the  session  key  Kab  and  identifying 
information,  a  similar  encrypted  message  for  B,  and  in  the  clear,  B’s  nonce,  Nb- 
A  forwards  the  second  part  verbatim  to  B,  and  attaches  Nb  encrypted  under  the 
session  key,  to  demonstrate  that  A  now  has  that  key. 

We  use  the  following  initial  assumptions,  which  are  typical  of  shared-key  pro¬ 
tocols: 


A\=A<^>S 

b\=b£±ls 

S\=B<^LS 

s^aAb 

A\=#(K) 

BN#(M) 

BN#  Pi) 

^4^5  controls  A  B 

11 5  controls  A 

Since  there  are  no  secrets  in  this  protocol,  other  than  the  assorted  keys,  we  can 
declare  all  principal  names,  nonces,  and  timestamps  public.  This  produces  the 
following  additional  initial  assumptions: 


A  ^  public(A)  B  ^  public(.4)  S  ^  public(A) 

A  |=  public(f?)  B  |ee  public (5)  S  |e=  public(5) 

A  ^  public(iVa)  B  ^  public(iV0)  S  ^  public (7Va) 

A  |==  public(A^)  B  J=  public(iV&)  S  |=  public (Nb) 

A  ^  public(Tfc)  B  |ee  public(Tb)  S  public(T6) 


We  could  instead  add  these  assumptions  on-demand,  as  the  verification  requires 
them.  This  would  yield  a  somewhat  smaller  set  of  assumptions,  which  is  in  gen¬ 
eral  a  desirable  goal.  We  could  further  reduce  this  set  of  assumptions  if  the  RV 
logic  were  extended  to  allow  principals  to  infer,  for  instance,  that  data  received 
unencrypted  must  be  public  (as  suggested  in  Section  4,3,1), 

Now  we  can  construct  the  necessary  interpretation  rules  for  this  protocol.  We 
start  with  the  most  obvious  message  fragments:  the  parts  of  M3  and  M4  encrypted 
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under  Kas  and  Kbs  must  (at  least)  convey  the  belief  A  B,  so  we  produce  the 
corresponding  interpretation  rules: 

Ngu  P^Q^R.N.K.T]  wst2:PMM 

P^QippJUR  P^QfppJ^R 

We  turn  now  to  the  second  part  of  message  M4:  {Nb}Kah.  Intuitively,  this  message 
confirms  for  B  that  A  has  the  session  key,  as  A  has  encrypted  the  fresh  nonce  TVj, 
using  it.  If  we  were  doing  a  simple  BAN  analysis  of  the  protocol,  we  might  be 
tempted  to  idealize  this  message  fragment  as 

IaAb  \ 

l-  >Kab 

so  that  we  achieve  this  final  result: 

B  |=  A^=  A^B 

In  RV,  though,  we  are  forced  to  be  more  careful.  As  the  protocol  description 
stands,  there  is  not  enough  information  in  the  concrete  message  {Nb}Kab  to  pro¬ 
duce  the  idealized  version  above:  B’s  name  is  not  given  explicitly.  We  could  try 
binding  Nb  to  B,  but  there  is  no  message  that  will  allow  A  to  trust  that  binding. 
Thus  when  B  sees  this  message,  he  knows  that  A  has  the  key  Kab,  but  he  cannot 
be  certain  that  A  believes  she  shares  that  key  with  B.  We  can  reach  this  weaker 
conclusion  without  needing  an  extra  interpretation  rule: 

B  t=  A.  |w  {Nb}Kab 

Will  the  two  interpretation  rules  above  (Nstl  and  Nst2)  suffice,  or  are  more 
necessary?  The  encrypted  component  of  message  M2  is  not  yet  interpreted.  Where 
encryption  occurs  in  a  protocol,  it  normally  serves  to  convey  beliefs  (in  which  case 
an  interpretation  is  normally  needed),  or  to  conceal  secrets,  or  both.  M2  contains 
no  secrets,  so  we  expect  that  it  is  intended  to  convey  beliefs.  Since  it  is  unclear 
what  beliefs  might  be  conveyed  by  this  message  or  required  by  the  verification, 
we  will  leave  the  message  uninterpreted  for  now. 

Given  the  interpretations  above,  we  can  check  the  honesty  property  for  this 
protocol  as  described  in  Section  5.1.  Messages  M3  and  M4  present  no  problems. 

zs 

The  server  believes  A  ^  B,  and  believes  further  that  Kas  and  Kbs  are  keys 
shared  with  A  and  B,  respectively,  so  we  can  derive 

S  N  legtt({[Atfat.Jl]}xJ 
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We  run  into  trouble  when  checking  honesty  for  the  encrypted  part  of  M2,  This 
message, 

{a.n„.  n}Kii 

can  be  confused  with  the  first  part  of  M*: 

{A.Kab.Tb}Kbs 

The  honesty  check  on  M2  reveals  this  because  it  applies  the  M4  interpretation  and 
requires  the  following  belief,  which  does  not  hold: 

b^bAs 

This  could  correspond  to  a  real  vulnerability  in  some  implementations.  An  eaves¬ 
dropper  could  record  M2  and  replay  the  encrypted  part  in  M4,  thus  convincing 
B  that  Na  is  the  session  key.  Since  the  eavesdropper  can  read  the  value  of  Na 
from  Mi,  it  is  now  able  to  masquerade  as  A  to  B.  The  simplest  solution  to  this 
problem  is  to  tag  the  encrypted  message  in  M2  to  distinguish  it  from  the  messages 
the  server  sends.  After  this  fix  is  applied,  the  honesty  check  succeeds. 

Having  checked  honesty,  we  can  proceed  to  secrecy.  The  secrecy  properties 
for  the  Neuman-Stubblebine  protocol  are  straightforward  to  check  and  not  partic¬ 
ularly  interesting  since  the  only  secret  ever  transmitted  is  the  session  key,  so  we 
will  move  on  to  feasibility. 

The  most  interesting  message  for  the  feasibility  check  is  M4.  We  must  verify 
that  A  can  produce 

[{[A.Kab-Tb\}Kbs .  {Ab}^] 

We  can  derive  this  from  the  information  A  receives  in  M3.  First,  we  derive  that  A 
sees  the  first  component  of  M4  by  extracting  the  second  part  of  M3: 

A  <  [ UB.Na.K*.Tt])K„  .  l[A.KQt.Tb}}K  -JVfr] 

4  <1 

Second,  we  derive  that  A  sees  Kab  by  decrypting  the  first  part  of  M3: 

[B .  Na.  Kai,.Tb] } 

A<j[B.Na.Kab.Tb] 

A  <  Kab 

Finally,  we  use  similar  steps  to  show  that  A  can  produce  {Nb}K  and  can  con¬ 
catenate  that  with  the  forwarded  part  of  M3  to  produce  the  full  message  M4. 
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These  belief  goals  for  Neuman-Stubblebine  follow  quickly  from  the  interpre¬ 
tations  and  concrete  protocol  given  above: 

A\=A<^B 
B^A^B 
B  N  A.  f=S  {Nb}Kab 

Ideally,  we  would  like  A  to  have  some  assurance  that  B  has  at  least  participated 
in  this  run  of  the  protocol.  (It  is  unrealistic  to  expect  A  to  believe  much  more  than 
that  about  B  since  B  sends  no  messages  after  receiving  the  session  key.)  Exam¬ 
ining  the  concrete  protocol,  we  see  that  A  receives  some  information  indirectly 
from  B:  both  the  nonce,  Nb,  and  the  timestamp,  Tb.  Can  A  be  sure  that  either  of 
these  was  recently  uttered  by  B1  She  can  if  we  interpret  the  message  S  sends  her 
a  bit  differently.  Consider  the  following  interpretation,  which  replaces  the  existing 
interpretation  with  the  same  premise: 

P  1=  Q  [R.N.K.T) 

P\=Q^(P  R,R^  N) 

Here  the  server  is  affirming  that  B  uttered  Na.  We  add  the  initial  assumption, 

^4^5  controls  B  (~  X  , 

indicating  that  A  trusts  S  to  tell  her  what  B  said.  We  can  then  use  v4’s  belief  that 
Na  is  fresh  to  reach  a  new  conclusion: 

A  |ee  B  («  Na 

Now  both  A  and  B  have  some  assurance  of  each  other’s  presence  in  the  protocol 
run.  Note  that  we  have  finally  made  use  of  the  encryption  in  M2;  without  it,  S 
would  not  believe  B  |~  Na,  and  could  not  pass  the  honesty  test  with  this  newly 
added  interpretation  rule. 

5.2.3  Woo-Lam  Public-key  Protocol 

In  1992,  Woo  and  Lam  proposed  the  following  “peer-peer  authentication  pro¬ 
tocol,”  which  uses  public-key  cryptography  to  establish  a  shared  session  key  for 
communication  between  A  and  B,  who  trust  S  to  generate  the  key  and  issue  signed 
public-key  certificates  [WL92a,  WL92b]: 
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Mi. 

A^S 

m2. 

S  ->  A 

Ms. 

A-^B 

m4. 

B^S 

M5. 

S->B 

Mb. 

B  —>  A 

m7. 

A-*  B 

[A.B] 

B.A.  {JV„}K.] 

{\A.K.]}k,  .  {{[N'.K*.A.B]}k,)  J 

'  [{[Na-Kab-A.B]}KI'  .N„] 


Here,  A  notifies  S  that  she  wishes  to  communicate  with  B.  S  provides  a  certificate 
of  B’s  public  key  (Kb),  then  A  sends  a  nonce  (Na)  to  B,  using  Kb.  InM4,  B  sends 
A’s  nonce,  encrypted,  to  S,  who  responds  with  a  certificate  of  A’s  public  key  and  a 
four-part  message  giving  the  session  key  (Kab).  B  decrypts  the  signed  session  key 
message,  adds  a  challenge  (Nb),  re-encrypts  it  for  A,  and  sends  it  along.  Finally, 
A  responds  to  B’s  challenge  by  encrypting  it  under  the  session  key. 

The  participants  will  hold  the  expected  initial  assumptions  regarding  keys: 


A  \=hA 
B^^B 
S\ee&A 

A  ^  S  controls  &  B 
yl  ^  5  controls  A  B 

Ka  =  K' 

Ks  =  K’-' 


A\=& S 
B  \=&S 

s\=a£±>b 

B  ^  S  controls  &  A 

B  |=  S  controls  A  B 

Kb  =  K'b~l 


Both  A  and  B  will  generate  secret  nonces  satisfying  these  assumptions: 

A£#(N„)  ,1  r  A  '*  B 

£N#(AW 

A  will  also  trust  the  server  not  to  disclose  its  nonce: 


A  ^  -9  maysee  Na 

Before  going  further  with  this  protocol,  we  should  make  a  correction.  The 
signed  public-key  certificates  the  server  sends  in  M2  and  the  first  part  of  M5  con¬ 
tain  no  timestamps,  nonces,  or  other  indications  of  their  freshness.  This  will  cause 
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the  belief-goal  verification,  as  well  as  other  tests,  to  fail.  In  practical  terms,  this 
means  that  once  a  principal’s  public  key  is  compromised,  an  adversary  who  has 
stashed  away  the  appropriate  certificate  can  pose  as  that  principal  forever.  This  er¬ 
ror  would  be  caught  in  a  standard  BAN  analysis,  so  we  will  not  explore  it  further. 
We  propose  the  following  corrected  protocol: 


Mi. 

A  - 

+  S: 

[A.B.Ta] 

M2. 

S- 

A : 

{\B.K„.T«}}k, 

m3. 

A  - 

->  B 

{W.-4U 

m4. 

B- 

->S: 

[b.a.  {[AT..r6]}K>] 

m5. 

S  —y  B 

{\A.Ka.n]}K, .  {{ \N„.K,i.A.B)}I<,}Kt ] 

m6. 

B 

-*  A 

m7. 

A  - 

+  B 

:  {Nb}Kab 

This  protocol  differs  from  the  original  in  that  timestamps  Ta  and  Tb  have  been 
added  to  messages  Mi,M2,M4,  and  M5.  A  single  server-assigned  timestamp 
could  be  used  instead,  but  that  would  require  synchronized  clocks.  In  this  version, 
A  and  B  only  check  timestamps  they  issued  themselves.  We  require  two  extra 
initial  assumptions: 

A|=#CTa)  B(s#(H) 

Again,  we  can  take  the  approach  of  constructing  interpretations  lazily,  as  the 
verification  requires  additional  beliefs.  The  most  obvious  interpretation  is  for  the 
message  containing  the  session  key  (the  second  part  of  M5): 

P  (=  S  [AT.AT.Q.fl] 

The  interpretation  of  the  server-generated  public  key  certificates  is  also  clear: 

P  j=  S  [QJCT] 

P\=Sfc&Q 

The  honesty  and  secrecy  analyses  for  this  protocol  as  stated  are  somewhat  in¬ 
volved.  We  again  let  every  principal  name  and  timestamp  be  public.  We  can 
derive  that  all  public  keys  are  public  from  the  public  RV  rules. 

A  ^  public(A)  B  ^  public(A)  S  ^  public(A) 

A  ^  public(B)  B  ^  public(B)  S  ^  public(B) 

A  ^  public(Ta)  B  |ee  public(Ta)  S  ^  public(T0) 

A  ^  pubIic(T6)  B  |=  public(Tb)  S  |=  public(T6) 
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We  will  look  at  each  message  briefly: 

•  Mi :  No  honesty  or  secrecy  issues  since  there  is  no  encryption  and  A  and  B 
are  public. 

•  M2:  B  and  Kb  are  public,  so  secrecy  is  maintained.  S  believes  the  interpre- 
tation  of  the  message  ( i-4  B),  so  honesty  is  satisfied. 

•  M3:  From 

A  ^  A  ^  B 
and 

A^=&B 

we  can  derive 

A  N  public(  { [Na  •  A]  ) 

Honesty  is  satisfied  trivially  since  there  is  no  interpretation. 

•  Mi’.  Here  we  hit  a  secrecy  snag:  B  does  not  believe  S  maysee  Na.  We  can 
safely  repair  this  by  making  the  interpretation  of  M4  include  the  statement 
S  maysee  N9  in  its  conclusion.  Honesty  is  satisfied  trivially, 

•  Ms:  Reasoning  for  the  first  part  is  the  same  as  for  M2.  For  file  second  part, 
S  can  derive  B  maysee  Kab  and  B  maysee  Na  if  we  interpret  M4  as  stating 

A^  B.  Honesty  follows  from  5”s  initial  assumptions. 

•  Ms:  The  first  part  passes  secrecy  if  we  add  the  interpretation  to  Ms  that 
A  maysee  [Na.Kab.A.B].  For  the  second  part,  B  can  derive  A  maysee  Nb 

Nh 

since  B  believes  A  ^  B,  Honesty  is  trivial. 

•  Mr:  If  we  add  the  interpretation  to  Ms  that  A  f*  B  then  we  satisfy  the 
secrecy  property.  Honesty  is  trivial. 

The  iterative  process  illustrated  above,  in  which  interpretations  are  refined  and 
assumptions  added  as  necessary  to  push  the  verification  through  allows  us  to  more 
easily  identify  the  assumptions  and  interpretations  that  are  crucial  and  those  that 
are  redundant  or  useless.  Backing  up  and  retrying  the  analysis  after  each  of  these 
changes  would  be  cumbersome  if  done  by  hand,  but  it  is  easy  when  assisted  by  a 
theory-generation-based  verifier. 


104 


CHAPTER  5.  THEORY  GENERATION  FOR  RV 


If  we  go  through  this  process  without  the  initial  assumptions  that  A  and  B 
believe  their  nonces  to  be  secret,  the  analysis  becomes  dramatically  simpler,  and 
we  find  that  we  can  achieve  the  same  set  of  belief  goals  without  relying  on  the 
secrecy  of  those  nonces.  The  concrete  protocol  is  clearly  designed  to  keep  the 
nonces  secret,  so  we  might  well  ask  what  the  consequences  would  be  of  removing 
the  extra  encryption.  If  we  compare  the  generated  theories  for  the  original  protocol 
with  a  modified  protocol  where  nonces  are  passed  in  the  clear,  we  find  that  the 
belief  goals  are  unaffected  by  the  change. 

In  fact  Woo  and  Lam  arrived  at  the  same  conclusion  in  a  followup  article  two 
months  after  the  original  [WL92b].  They  suggest  a  simplified,  five-step  protocol 
in  which  the  nonces  are  not  kept  secret.  This  protocol  meets  the  same  belief  goals 
as  the  original. 


s 


Chapter  6 

Implementation 


In  this  chapter,  we  discuss  the  Revere  protocol  verification  system  and  its  im¬ 
plementation  of  the  TGf  algorithm,  show  how  it  supports  standard  belief  logics  as 
well  as  extended  analysis  with  RV,  and  present  some  performance  measurements 
for  the  system. 

The  Revere  tool  contains  a  general-purpose  theory  generation  core,  but  its 
interface  is  tailored  to  the  protocol  analysis  domain.  It  uses  RV  as  well  as  other 
belief  logics,  and  the  core  could  be  reused  to  perform  theory  generation  with  any 
logic  meeting  the  restrictions  laid  out  in  Chapter  2. 

Revere  is  written  primarily  in  the  Standard  ML  (SML)  programming  lan¬ 
guage  [MTH90,  MTHM97].  SML  is  a  mostly  functional,  strongly  typed  lan¬ 
guage  with  exceptions  and  a  sophisticated  module  system.  It  supports  user-defined 
datatypes  with  a  pattern  matching  syntax  that  allows  very  natural  manipulation  of 
formulas  and  expressions.  A  formal  semantics  for  SML  has  been  published,  mak¬ 
ing  it  especially  appropriate  as  a  basis  for  building  verification  systems.  Revere 
makes  significant  uses  of  SML’s  module  system,  some  of  which  are  described  in 
the  following  sections.  We  first  address  issues  relating  to  the  implementation  of 
TGf  itself. 


6.1  TG^  Algorithm  Implementation 

The  T implementation  within  Revere  takes  as  input  a  module  containing  the 
rules  and  rewrites  for  a  logic,  and  produces  a  module  which  is  specialized  to  per¬ 
forming  theory  generation  for  that  logic.  This  generated  module  includes  a  func¬ 
tion  (closure)  which  performs  theory  generation  given  an  initial  set  of  formulas 
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signature  TGL  = 
sig 

structure  Logic  :  LOGIC 

type  formula  =  Logic. RuleTypes .Fol .term 
type  s_rule  =  Logic  .RuleTypes .  s .rule 
type  theory _rep 

val  closure  :  s.rule  list  ->  formula  list 

->  theory.rep 

val  closure.add  :  theory.rep  ->  formula  list 

->  theory.rep 

val  derivable  ;  theory_rep  ->  formula  ->  bool 
val  all-formulas  ;  theory.rep  ->  formula  list 
end 


Figure  6.1:  Signature  for  the  theory  generation  module 

and  an  optional  set  of  extra  S-rules  to  use.  The  module  matches  the  tgl  signature 
given  in  Figure  6.1,  and  contains  three  functions  in  addition  to  closure. 

The  closure.add  function  takes  an  already-generated  theory  representation 
and  a  set  of  new  formulas,  and  generates  a  representation  of  the  theory  induced  by 
the  old  and  new  formulas  together.  This  function  is  particularly  useful  for  RV  veri¬ 
fications,  in  which  we  must  do  theory  generation  for  the  initial  assumptions  alone, 
then  the  initial  assumptions  plus  the  first  message,  and  so  on.  The  implementation 
of  closure.add  is  described  in  Section  6.1.1. 

The  derivable  function  takes  a  generated  theory  representation  and  a  for¬ 
mula,  and  determines  whether  the  formula  is  in  the  theory.  This  function  is  exactly 
the  decision  procedure  presented  in  Section  2.4.2. 

The  purpose  of  all.f  ormulas  is  simply  to  provide  access  to  the  set  of  formu¬ 
las  in  a  theory  representation,  so  that  other  modules  can  compare  theories,  present 
them  to  the  user,  and  store  them. 

Logics  (such  as  BAN  and  RV)  are  represented  by  modules  matching  the  LOGIC 
signature  in  Figure  6.2,  which  refers  to  the  datatypes  corresponding  to  S-rules,  G- 
rules,  and  rewrites,  laid  out  in  the  ruletypes  signature.  A  logic  module  spec¬ 
ifies  the  S-rules,  G-rules,  and  rewrites,  as  well  as  the  ■<  pre-order  (no.larger). 

To  create  a  theory  generation  module  for  a  particular  logic  such  as  BAN,  we 
apply  the  general-purpose  tgl  functor. 


6.1.  TGe  ALGORITHM  IMPLEMENTATION 
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signature  RULETYPES  = 
sig 

Structure  Fol  ;  FOL 
type  formula  =  Fol. term 
datatype  rewrite  = 

Rewrite  of  pair:  formula  *  formula, 
name:  string 
datatype  s_rule  = 

S-Rule  of  premises:  formula  list, 

conclusions:  formula  list, 
name;  string 
datatype  g_rule  = 

GJRule  of  premises:  formula  list, 
conclusion:  formula, 
name  :  string 

end 

signature  LOGIC  = 
sig 

structure  RuleTypes  :  RULETYPES 
type  formula  =  RuleTypes . formula 
val  S_rules  :  RuleTypes . s.rule  list 
val  G_rules  ;  RuleTypes . g.rule  list 
val  rewrites  :  RuleTypes . rewrite  list 
val  no^larger  ;  formula  *  formula  ->  bool 
end 


Figure  6.2:  Signature  for  describing  £rw  logics 

structure  BanTGL  :  TGL  = 

MakeTGL ( structure  Logic  =  Ban  ...) 

A  functor  is  an  SML  construct  that  creates  a  module  (structure)  given  other  mod¬ 
ules  as  parameters,  In  this  case,  the  Ban  structure  is  passed,  along  with  some 
additional  structure  arguments  omitted  here,  MakeTGL  performs  assorted  checks 
and  does  some  pre-computation  to  facilitate  the  theory  generation  process. 

6.1.1  Data  Structures  and  Optimizations 

Revere  makes  use  of  a  few  specialized  data  structures  for  representing  formulas. 
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rules,  rewrites,  and  the  relationships  among  them,  and  uses  some  optimizations 
and  heuristics  to  speed  up  theory  generation.  We  describe  a  few  here. 

Many  operations  in  TG*  manipulate  sets  of  formulas.  In  particular,  the  set 
of  formulas  constituting  the  partially  generated  theory  is  added  to  by  closure  and 
iterated  over  by  backward. chain -one  in  searching  for  formulas  matching  a  given 
pattern  (see  Section  2.3).  We  accelerate  the  process  of  searching  for  matches  by 
observing  that  the  number  of  patterns  ever  matched  against  is  limited:  all  pat¬ 
terns  are  instances  of  S-  or  G-rule  premises,  and  many  patterns  are  exactly  those 
premises.  We  keep  along  with  the  set  of  formulas  a  table  mapping  each  premise  to 
all  formulas  in  the  set  that  match  it.  Then,  when  we  need  to  find  all  matches  for  a 
pattern,  P,  we  can  accelerate  the  search  by  restricting  it  to  those  formulas  known 
to  match  the  premise  of  which  P  is  an  instance.  Each  time  a  formula  is  added  to 
the  set,  it  is  matched  against  each  of  the  premises  and  added  to  the  appropriate 
sets.  In  principle,  we  could  do  further  refinement  of  this  table  to  include  some 
patterns  that  are  partially  instantiated  premises,  but  for  the  typical  verifications 
we  attempted,  the  overhead  would  not  be  justified. 

To  further  accelerate  theory  generation,  we  make  the  implementation  of  the 
apply srule  function  (Section  2.3.2)  aware  of  which  formulas  are  in  the  fringe. 
By  propagating  this  information,  we  enable  the  function  to  select  only  those  S- 
rule  applications  that  make  use  of  formulas  from  the  fringe,  since  any  other  S-rule 
applications  must  already  have  been  done.  The  representation  described  above 
requires  us  to  match  the  new  formulas  against  all  premises  already,  so  it  costs  little 
to  add  this  optimization,  and  it  eliminates  a  considerable  number  of  redundant  rule 
applications. 

Since  RV  verification  requires  theory  generation  for  each  step  of  the  protocol, 
we  provide  the  closure_add  function  (Figure  6.1),  for  adding  new  formulas  to 
a  generated  theory.  A  trivial  implementation  of  closure.add  could  just  invoke 
TGf  on  the  set  containing  the  old  theory  representation  and  the  new  formulas. 
To  accelerate  the  search,  however,  we  take  advantage  of  the  knowledge  that  the 
old  theory  representation  is  closed.  We  treat  the  new  formulas  as  the  fringe,  and 
the  old  theory  representation  as  a  partial  theory  representation.  This  gives  the 
closure  function  a  “head  start”  when  combined  with  the  apply.srule  opti¬ 
mization  above. 

Finally,  the  process  of  unifying  modulo  rewrites  involves  frequent  invocations 
of  a  function  that  applies  rewrites  to  a  term  at  the  outermost  level,  in  all  possible 
ways.  With  many  rewrites,  this  process  can  become  quite  expensive,  so  we  use 
limited  memoization  to  save  some  computation. 


6.2.  REVERE  SYSTEM  STRUCTURE 
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datatype  protocol  = 

REVEREPROTOCOL  of 
{  name  :  string, 

assumptions  :  Logic . formula  list, 
messages  :  {  sender  ?  Logic , formula , 

receiver  :  Logic . formula , 
message  ;  Logic , formula  }  list, 
goals  :  Logic . formula  list, 

interpretations  :  Logic , RuleTypes . s.rule  list, 

...  >  . 

Figure  6.3:  SML  datatype  representing  a  protocol  in  REVERE 

6.2  Revere  System  Structure 

Beyond  the  theory  generation  core,  the  Revere  system  provides  a  simple  veri¬ 
fication  environment  tailored  for  protocols.  The  user  interface  is  a  menu-driven 
XEmacs  package  that  interacts  behind  the  scenes  with  the  SML  theory  generation 
engine.  Logics  and  protocols  are  represented  internally  as  SML  modules  (struc¬ 
tures);  logics  match  the  LOGIC  signature  given  earlier,  and  protocols  are  values 
of  the  protocol  type  defined  in  Figure  6.3.  The  initial  assumptions,  messages, 
and  desired  belief  goals  are  all  given  as  formulas  in  the  appropriate  logic.  For  RV 
verifications,  interpretations  can  be  provided  as  a  set  of  extra  rules  that  will  be 
used  in  theory  generation. 

A  front-end  parser  converts  user- written  protocol  specifications  to  these  SML 
values.  The  protocol  specification  language  is  a  variant  of  CAPSL,  an  emerging 
standard  for  cryptographic  protocol  description  [Mil97] . 

The  user  interface  provides  different  ways  to  sort,  filter,  and  display  generated 
theories,  and  allows  comparing  the  generated  theories  for  two  protocols.  There  is  a 
special  RV  support  module  providing  interpretation  validation  as  well  as  honesty, 
secrecy,  and  feasibility  checks, 


6.3  Performance 

The  Revere  theory  generation  implementation  is  simple — the  core  is  roughly 
1000  lines  of  code — and  it  could  be  further  optimized  in  various  ways  as  described 
in  Chapter  7.  Nonetheless,  its  performance  on  the  examples  we  have  used  is 
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Logic 

Protocol 

Elapsed  TG  Time 

BAN 

Kerberos 

4.7s 

Andrew  RPC 

3.2s 

Needham-Schroeder  (Shared) 

1.5s 

CCITT  X.509 

23.8s 

Wide-Mouth  Frog 

19.3s 

Yahalom 

23.0s 

AUTLOG 

challenge-response  1 

0.3s 

challenge-response  2 

0.3s 

Kerberos 

11.3s 

Kailar’s 

Accountability 

IBS  variant  1 

0.3s 

IBS  variant  2 

0.3s 

SPX  Auth.  Exchange 

0.2s 

RV 

Needham-Schroeder  (Pub) 

23.0 

Otway-Rees 

34.4 

Denning-Sacco 

38.1 

Neuman-Stubblebine 

20.1s 

Woo-Lam 

50.8s 

Figure  6.4:  Elapsed  theory  generation  times  in  Revere  for  various  protocols.  All 
timings  were  done  on  an  Digital  AlphaStation  500,  with  500MHz  Alpha  21164 
CPU. 

suitable  for  interactive  use.  The  table  in  Figure  6.4  shows  that  the  elapsed  theory 
generation  time  for  all  examples  was  less  than  one  minute.  All  other  operations 
take  insignificant  time.  It  is  certainly  conceivable  that  logics  and  specifications 
in  another  domain  could  cause  this  theory  generation  implementation  to  exhibit 
unacceptable  performance.  The  presence  of  very  long  sequences  in  messages  or 
rules  can  cause  slowdowns,  as  canonicalization  and  unification  modulo  rewrites 
become  expensive.  In  Chapter  7  we  discuss  specialized  support  for  associative- 
commutative  operators  that  would  significantly  alleviate  this  problem.  Logics 
containing  a  very  large  number  of  rules,  and  especially  those  in  which  G-rules 
play  a  dominant  role  in  reasoning,  could  prove  inefficient  to  manage  as  well;  better 
rule-selection  optimizations  would  be  necessary  to  reduce  this  cost.  For  the  cases 
we  have  studied,  however,  the  theory  generation  speed  was  satisfactory,  making 
these  optimizations  unwarranted. 


Chapter  7 

Conclusions  and  Future  Directions 


In  this  chapter,  we  conclude  by  summarizing  the  results  of  the  thesis  work,  which 
support  the  two  parts  of  the  thesis  claim  from  Section  1.2,  and  by  suggesting 
avenues  for  further  research,  which  range  from  minor  algorithm  tuning  to  broad 
areas  for  exploration. 

IX  Summary  of  Results 

First,  we  conclude  that  theory  generation  is  an  effective  method  of  automated 
reasoning.  In  support  of  this  claim,  we  have  produced  several  artifacts  and  made 
observations  of  them.  We  have  described  a  simple  algorithm  (TG^)  for  producing 
finite  representations  of  theories.  This  algorithm  can  be  applied  to  any  logic  in 
the  £rw  class  that  also  meets  the  preconditions  in  Definition  2.16.  The  theory 
representations  produced  by  TG^  are  well  suited  to  direct  comparison  since  they 
are  nearly  canonical,  and  they  can  also  be  used  in  an  efficient  decision  procedure. 
We  have  proved  that  the  TG^  algorithm  and  this  decision  procedure  terminate  and 
are  correct. 

As  further  evidence  of  the  effectiveness  of  theory  generation,  we  have  pro¬ 
duced  a  practical  implementation  including  several  optimizations  that  improve  on 
the  basic  TG*  algorithm.  We  have  successfully  incorporated  this  implementation 
into  anew  protocol  analysis  system,  Revere,  where  theory  generation  serves  sev¬ 
eral  purposes.  Revere  verifies  specific  properties  of  protocols  using  the  theory- 
generation-based  decision  procedure,  compares  protocols  by  displaying  the  dif¬ 
ference  between  their  respective  theory  representations,  and  does  message-by¬ 
message  analysis  using  incremental  theory  generation.  Through  many  protocol 
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analyses  using  four  different  logics,  we  have  observed  that,  in  practice,  the  theory 
generation  completes  quickly  (in  seconds  or  minutes),  and  that  the  theory  repre¬ 
sentations  generated  are  consistently  of  manageable  size. 

We  support  the  second  part  of  the  thesis  claim,  that  theory  generation  can  be 
applied  to  security  protocols  to  analyze  a  wide  range  of  critical  security  prop¬ 
erties,  by  various  example  applications  of  the  Revere  tool.  We  used  Revere 
(and  thus  theory  generation)  to  verify  the  properties  that  can  be  expressed  by  the 
three  existing  belief  logics  described  in  Chapter  3:  the  BAN  logic  of  authenti¬ 
cation,  AUTLOG,  and  Kailar’s  accountability  logic.  These  properties  include, 
for  idealized  authentication  and  key  exchange  protocols,  beliefs  regarding  pub¬ 
lic  and  shared  keys,  secrets,  freshness,  and  statements  made  by  other  principals. 
For  idealized  electronic  commerce  protocols,  we  can  also  check  non-repudiation 
properties  (“A  can  prove  X  to  B”).  Using  Revere,  we  reproduced  published 
protocol  analyses  using  these  belief  logics,  and  in  some  cases  we  exposed  errors 
in  the  earlier  analyses. 

Beyond  these  existing  logics,  we  have  developed  a  new  logic,  RV,  which  al¬ 
lows  more  grounded  reasoning  about  protocols,  in  that  the  mapping  from  concrete 
messages  to  abstract  meanings  is  made  explicit.  Using  theory  generation,  we  have 
applied  this  logic  to  several  existing  protocols,  checking  honesty,  secrecy,  feasi¬ 
bility,  and  interpretation  validity  properties.  These  properties  are  not  fully  ad¬ 
dressed  by  other  belief  logics,  and  they  are  critical  in  that  failure  to  check  them 
can  lead  (and  has  led)  to  vulnerabilities.  Like  other  belief  logics,  RV  takes  a  con¬ 
structive  approach  to  protocol  verification,  in  that  it  focuses  on  deriving  positive 
protocol  properties,  rather  than  searching  for  attacks.  Through  extending  this  ap¬ 
proach  to  honesty  and  secrecy  properties,  RV  can  expose  flaws  that  correspond  to 
concurrent-run  attacks  without  explicitly  modeling  either  an  intruder  or  some  set 
of  runs.  In  the  model  checking  approaches,  one  must  typically  establish  bounds 
on  the  number  of  protocol  runs,  and  sometimes  also  specify  an  intruder  endowed 
with  a  specific  set  of  capabilities.  In  return,  however,  when  a  property  fails  to 
hold,  the  model  checkers  can  supply  a  counterexample,  which  in  this  domain  usu¬ 
ally  correspond  to  attacks. 

Through  this  work  we  have  learned  (or  re-learned)  other  valuable  lessons.  Per¬ 
haps  the  most  glaring  is  that  formal  arguments,  no  matter  how  trivial,  should  not 
be  trusted  until  they  have  been  subjected  to  mechanical  verification.  Again  and 
again  we  find  manual  proofs  that  appear  completely  sound  and  yet  rely  on  unstated 
assumptions  or  intuitively  obvious  steps  that  are  not  formally  warranted.  The  de¬ 
velopment  of  a  new  logic,  a  particularly  perilous  undertaking,  should  always  be 
done  with  the  assistance  of  automated  verification  to  ensure  that  the  logic  is  truly 
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powerful  enough  to  prove  what  it  is  intended  to  prove.  Of  course,  mechanical 
verification  is  not  in  itself  sufficient  to  provide  full  confidence.  It  serves  to  com¬ 
plement  human  understanding  of  the  formalized  assumptions  and  conclusions  at 
the  “edges”  of  the  verification  process. 

Finally,  the  theory  generation  approach  has  its  limitations.  The  TG^  precon¬ 
ditions  can  be  somewhat  cumbersome  to  establish,  although  in  most  cases  they 
can  be  handled  relatively  easily  by  using  standard  pre-orders.  Theory  generation, 
and  the  TG^  algorithm  in  particular,  are  not  well-suited  to  all  logics;  for  instance, 
logics  encoding  arithmetic  and  temporal  logics  are  probably  poor  candidates.  For 
some  sets  of  rewrites,  the  unification  modulo  rewrites  can  be  expensive;  one  typi¬ 
cal  example  is  a  set  of  rewrites  encoding  associative  and  commutative  properties, 
applied  to  assumptions  or  rules  that  involve  long  sequences.  The  enhancements 
to  theory  generation  described  in  the  next  section  could  address  some  of  these 
shortcomings. 

7.2  Future  Work 

We  can  divide  directions  for  future  work  into  those  relating  to  theory  generation 
in  general,  and  those  applicable  to  the  security  domain  in  particular. 

7.2.1  Theory  Generation  Refinements  and  Applications 

The  TGf  algorithm  itself  could  be  enhanced,  or  its  preconditions  relaxed,  in  a 
variety  of  ways.  We  look  at  the  termination  guarantees  first. 

The  purpose  for  most  of  the  preconditions  is  to  ensure  that  TG*  will  always 
terminate,  but  there  is  a  tradeoff  between  making  the  preconditions  easy  to  check 
and  allowing  as  many  logics  as  possible.  The  preconditions  given  in  Defini¬ 
tion  2.16  are  sufficient  but  not  necessary  to  ensure  termination.  We  could  replace 
them  with  the  simple  condition  that  each  S-rule  application  must  produce  a  for¬ 
mula  no  larger  than  any  of  the  formulas  used  (perhaps  through  G-rules)  to  satisfy 
its  premises.  This  imposes  a  considerable  burden  of  proof,  but  it  is  a  more  per¬ 
missive  precondition  than  the  one  we  use.  Furthermore,  while  it  is  sufficient  to 
ensure  that  a  finite  theory  representation  exists,  it  is  not  sufficient  to  ensure  termi¬ 
nation,  as  we  must  also  prove  that  each  S~rule  application  attempt  must  terminate. 
In  some  cases,  this  extra  effort  may  be  justified  by  the  increased  flexibility. 

It  can  be  tricky  to  construct  the  ^  pre-order,  as  Section  3.1.1  makes  clear. 
However,  in  practice  we  may  sometimes  be  fairly  confident  that  a  suitable  pre- 
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order  exists  but  not  want  to  go  through  the  trouble  of  producing  it.  We  can  skip 
specifying  the  pre-order  if  we  are  willing  to  accept  the  risk  of  non-termination. 
Correctness  will  not  be  sacrificed,  so  if  the  algorithm  terminates,  we  can  be  sure 
it  has  generated  the  right  result. 

As  an  alternative  approach  to  ensuring  termination,  we  could  draw  on  existing 
research  in  automatic  termination  analysis  for  Prolog — for  instance  the  approach 
proposed  by  Lindenstrauss  and  Sagiv  [LS97] — to  check  whether  a  set  of  rules  will 
halt.  This  would  require  either  adjusting  these  methods  to  take  account  of  our  use 
of  rewrites,  or  perhaps  encoding  the  TG*  algorithm  itself  as  a  Prolog  program 
whose  termination  could  be  analyzed  in  the  context  of  a  fixed  set  of  rules  and 
rewrites. 

To  improve  the  performance  of  TG*,  we  could  introduce  a  special  case  to 
handle  associative-commutative  rewrites  efficiently,  using  known  techniques  for 
associative-commutative  unification.  The  general-purpose  unification  modulo 
equalities  implemented  for  Revere  has  acceptable  performance  for  the  exam¬ 
ples  we  ran,  but  it  could  become  expensive  when  formulas  or  rules  include  long 
sequences.  We  might  also  get  better  performance  in  searching  for  formulas 
matching  a  given  pattern  by  adapting  the  Rete  algorithm  used  in  some  AI  sys¬ 
tems  [For82]. 

The  TGf  algorithm  could  be  modified  quite  easily  to  keep  track  of  the  proof 
of  each  derived  formula.  This  information  could  prove  useful  in  providing  feed¬ 
back  to  the  user  when  the  verification  of  some  property  fails;  we  could,  for  in¬ 
stance,  automatically  fill  in  “missing”  side  conditions  in  an  attempt  to  push  the 
proof  through,  and  then  display  a  proof  tree  with  the  trouble  spots  highlighted. 
The  proofs  could  also  be  fed  to  an  independent  verifier  to  double-check  the  TG* 
results. 

Thinking  further  afield,  we  might  consider  extensions  such  as  providing  theory 
representations  other  than  the  (R,  R')  representations  described  in  Definition  2.9, 
or  even  representations  other  than  sets  of  formulas  in  the  target  logic.  These  alter¬ 
native  theory  representations  might  prove  necessary  in  applying  theory  generation 
to  domains  other  than  security  protocols.  In  looking  for  other  such  domains,  we 
should  keep  in  mind  the  features  of  the  security  protocol  domain  that  make  it 
amenable  to  theory  generation:  subtle  properties  of  the  domain  can  be  captured 
by  very  simple  rules,  the  verification  problems  involve  small  numbers  of  distinct 
entities  (keys,  messages,  principals,  nonces,  etc.),  and  the  properties  of  interest 
can  be  succinctly  expressed  by  relatively  small  formulas. 
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7.2.2  Enhancements  to  the  RV  Logic  and  Revere 

Beyond  improvements  to  the  theory  generation  method,  we  can  suggest  several 
possible  ways  to  strengthen  the  RV  logic  and  the  Revere  tool. 

Support  for  secure  hash  functions  would  be  a  useful  incremental  RV  extension; 
AUTLOG  and  other  belief  logics  provide  such  support  already,  so  the  main  task 
would  be  to  determine  what  the  legitimate  interpretations  of  a  secure  hash  are. 

RV  could  express  more  protocols  if  it  provided  a  notion  of  skolem  principals. 
The  purpose  of  such  a  principal  is  to  act  as  a  place-holder  when  a  principal’s 
identity  is  not  (yet)  known.  This  concept  could  prove  useful  in  cases  like  the 
following.  Suppose  A  initiates  a  protocol  run  with  B  by  sending  the  message, 

{\A.B.K..N«}}Kb  , 

in  which  A  is  introducing  herself  to  B,  and  providing  her  public  key  (Kg)  and  a 
secret  the  two  will  share  (Na).  At  this  point,  B  does  not  yet  know  with  confidence 
who  A  is,  but  B  should  be  able  to  conclude  that  he  can  safely  transmit  the  secret, 
Na,  encrypted  under  the  key  Ka.  To  represent  this  belief,  we  can  say  that  B  knows 
there  exists  some  principal,  P,  such  that  &  P  and  P  B.  By  introducing 
a  skolem  principal  to  represent  P,  we  can  demonstrate  that  B  does  not  violate 
secrecy  later  in  the  protocol  run. 

The  feasibility  check  in  RV  could  be  extended  to  include  demonstrating  that 
each  participant  knows  what  decryption  keys  to  use,  which  nonce  values  to  check 
received  messages  against,  and  other  such  knowledge.  This  would  require  mod¬ 
elling  protocols  more  like  little  programs,  as  some  model-checking  approaches 
do  [DDHY92,  CJM98]. 

Perhaps  the  most  challenging  aspect  of  specifying  a  protocol  in  RV  or  other 
belief  logics  is  constructing  the  message  interpretations  (idealizations).  Providing 
some  automated  support  for  this  process  could  greatly  improve  the  usability  of 
a  tool  like  Revere.  One  approach  that  seems  promising  is  to  assume  that  each 
message  is  intended  to  convey  all  the  beliefs  the  sender  has  at  the  time  he  sent  it. 
The  resulting  interpretation  will  almost  certainly  be  invalid,  but  we  can  remove 
beliefs  from  the  interpretation  until  it  becomes  valid.  The  result  would  be,  in 
some  sense,  a  maximal  valid  interpretation,  and  might  suffice  for  at  least  some 
protocols. 

The  Revere  tool  could  benefit  from  a  strongly  typed  model  for  protocols 
and  logics,  in  which  keys,  nonces,  principal  names,  and  so  forth  are  members 
of  distinct  types.  This  should  help  catch  some  simple  errors  in  specifications 
and  rules,  such  as  function  arguments  out  of  order.  More  importantly,  though. 
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the  information  could  be  used  to  automatically  tag  concrete  message  components 
(and  their  corresponding  interpretations)  with  the  appropriate  type.  Such  a  model 
would  match  an  implementation  in  which  it  is  always  possible  to  distinguish,  e.g., 
keys  from  principal  names.  Where  the  implementation  does  not  warrant  this  as¬ 
sumption,  the  user  could  specify  type  equivalences  to  indicate  which  types  can  be 
confused. 

Finally,  in  this  work,  we  focus  on  analyzing  one  protocol  at  a  time.  How¬ 
ever,  in  practice,  suites  of  related  protocols  must  often  coexist.  This  creates  the 
possibility  that  some  attack  may  make  use  of  runs  of  two  different  protocols.  If, 
however,  we  use  the  same  set  of  interpretations  and  initial  assumptions  in  analyz¬ 
ing  each  protocol  in  a  suite,  we  should  be  able  to  detect  vulnerabilities  to  such 
attacks. 


7.3  Closing  Remarks 

In  this  thesis  we  introduced  theory  generation,  a  new  general-purpose  technique 
for  performing  automated  verification.  Theory  generation  borrows  from,  and 
complements,  both  automated  theorem  proving  and  symbolic  model  checking, 
the  two  major  approaches  that  currently  dominate  the  field  of  mechanical  rea¬ 
soning.  Broadly  speaking,  theory  generation  provides  more  complete  automation 
than  theorem  proving,  but  with  less  generality.  Likewise,  theory  generation  has 
the  advantage  over  model  checking  of  producing  conclusive  proofs  of  some  cor¬ 
rectness  properties  without  arbitrary  bounds,  while  it  is  less  well  suited  than  model 
checking  to  proving  temporal  properties  and  producing  useful  counterexamples. 
This  thesis  has  demonstrated  the  utility  of  theory  generation  for  analyzing  security 
protocols,  but  this  is  only  a  start;  further  investigation  will  tell  whether  it  can  yield 
similar  benefits  in  other  domains. 

We  do  not  yet  have  a  complete  solution  to  security  protocol  verification;  per¬ 
haps  that  is  an  unattainable  goal.  However,  today  we  can  provide  substantial 
support  for  the  design  and  analysis  of  these  protocols,  and  potential  sharing  of 
information  among  different  tools  via  CAPSL.  A  thorough  protocol  design  pro¬ 
cess  should  start  with  adherence  to  principles  and  guidelines  such  as  Abadi  and 
Needham’s  [AN96].  The  designers  could  apply  theory  generation  with  RV  or 
other  belief  logics  to  prove  that  the  protocol  meets  its  goals  and  make  explicit 
the  assumptions  on  which  the  protocol  depends.  They  could  use  symbolic  model 
checkers  to  generate  attack  scenarios.  With  interactive,  automated  theorem  prov¬ 
ing  systems,  they  could  demonstrate  that  the  underlying  cryptography  meets  its 
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requirements,  and  make  the  connection  between  the  protocol’s  behavior  and  that 
of  the  system  in  which  it  is  used.  Finally,  the  proposed  protocol  could  be  pre¬ 
sented  for  public  review,  so  that  others  might  independently  apply  their  favorite 
formal  and  informal  methods.  Each  step  in  this  process  focuses  on  some  level  of 
abstraction  and  emphasizes  some  set  of  properties,  in  order  to  build  confidence  in 
the  protocol  and  the  system. 
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Appendix  A 

Equivalence  of  £rw  and  Cr 


This  appendix  contains  the  proof  of  Theorem  2.1,  which  shows  the  correspon¬ 
dence  between  £rw  and  £=: 

If  cj>  is  a  formula  of  £rw,  and  T  is  a  set  of  formulas  of  £rw,  then 

r  bw  <t> 

if  and  only  if 

ruf?u  w\-c=  <t> 

Proof:  We  start  with  the  forward  direction:  that  any  formula,  4>,  which  can 
be  proved  in  £rw  given  assumptions,  I\  can  also  be  proved  in  Cr  using  those 
same  assumptions  plus  the  rules  and  rewrites  of  iRW,  R  and  W.  We  proceed  by 
induction  on  the  length  of  the  proof  of  <f  in  £rw> 

In  the  base  case,  0  has  a  single-step  proof,  and  must  therefore  be  some  for¬ 
mula  in  T  or  the  instantiated  conclusion  of  a  rule  in  R  with  no  premises.  In 
either  case  (j>  can  be  proved  in  £r  by  introducing  the  formula  from  T  or  the  rule 
from  R,  possibly  followed  by  instantiation  (introduction  of  an  axiom  of  the  form, 
( yx.<p(x ))  4>(t),  followed  by  modus  ponens). 

For  the  induction  step,  we  have  three  cases,  depending  on  the  rule  of  inference 
used  in  the  last  step  of  the  n-step  proof  (in  £rw)<  We  can  ignore  the  case  where 
the  last  line  of  the  proof  is  an  axiom  or  assumption,  since  the  reasoning  from  the 
base  case  applies.  The  three  cases  follow: 

•  Case:  The  last  proof  step  is  application  of  a  rule  in  R  Let  the  rule  applied 
be 
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There  exists  a  substitution,  a,  such  that  aC  is  the  new  conclusion  (</>),  and 
there  must  exist  proofs  in  IRw  of  fewer  than  n  steps  (from  T)  of  each  of  the 
o By  the  induction  hypothesis,  there  exist  proofs  in  Cr  (from  riJjRU  W) 
of  the  <7 Pi.  We  can  concatenate  these  proofs,  then  add  the  rule  from  R, 

VPVC.(Pi  A  •••  A  Pm=>C) 

then  instantiate  this  rule  with  a  and  apply  modus  ponens  to  produce  the 
following: 

oP\  A  •  •  •  A  cPm  =>•  crC ) 

Applying  modus  ponens  again  with  propositional  tautologies,  we  arrive  at 

oC 


so  the  proof  in  C~  is  complete. 

•  Case:  The  last  proof  step  is  instantiation.  Instantiation  in  £rw  can  be  simu¬ 
lated  easily  in  C~  by  introducing  an  instantiation  axiom: 

( yx.(f>(x ))  =$>  (f)(t ) 

and  applying  modus  ponens. 

•  Case:  The  last  proof  step  is  a  substitution  of  equal  terms  using  an  equality 
in  W.  Let  the  equality  be  T\  =  T2.  There  exists  a  substitution,  a ,  and  a  for¬ 
mula,  p(Si, Sm),  such  that  T  \~tRW  p(Si, . . . ,  Sm)  has  a  proof  of  fewer 
than  n  steps,  and  0  is  [T,2\T1]p(5'i, . . . ,  Sm).  By  the  induction  hypothesis, 
rU-RUW  \-£=  G.  We  can  extend  this  Cr  proof  as  follows.  First,  introduce 
the  rewrite  from  W : 

T\  =  T2 

Next,  introduce  equality  axioms  for  each  of  the  Si'. 

(T2  =  Tx  A  r2  =  T2)  [T2\T2]5,  =  [T2\Ti]Si 

Apply  propositional  tautologies  to  yield,  for  each  Sit 

=  m Tx]Si 

Finally,  we  can  use  the  fourth  equality  axiom  with  propositional  tautologies 
to  get 

p([ra\T1]Si,...,[T2\Ti]Sm) 
which  completes  the  proof  of  tj>  in  Cr. 
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This  completes  the  proof  that  if  4>  is  derivable  in  £rw  from  T,  (j)  must  also  be 
derivable  in  C=  from  the  corresponding  assumptions. 

We  now  turn  to  the  reverse  direction:  any  formula,  (j>,  which  can  be  proved  in 
Cr  from  ruUUH7  must  also  have  a  proof  from  T  in  £rw- 

We  appeal  to  the  well-known  result  that  the  resolution  principle  is  complete 
for  clauses  in  first-order  logic  [CL73],  Resolution  is  an  inference  rule  that  consists 
of  applying  substitutions  to  two  clauses  (disjunctions  of  terms),  then  generating 
a  new  clause  by  combining  the  disjuncts  from  both  clauses  and  eliminating  pairs 
of  clauses,  (t,  -it).  All  rules  in  R  are  Horn  clauses  (clauses  with  at  most  one 
positive  disjunct).  For  such  formulas,  resolution  corresponds  to  satisfying  and 
removing  a  premise  of  the  rule,  and  any  sequence  of  resolution  steps  that  produces 
a  formula  of  £rw  from  a  rule  in  R  and  some  set  of  facts  (formulas  of  £rw)  can 
be  simulated  in  £rw  by  applying  an  instance  of  that  rule  and  using  those  facts  to 
satisfy  its  premises.  It  follows  that  any  formula  of  £rw  that  can  be  proved  in  C 
from  r  U  R  U  W  can  also  be  proved  from  T  in  £rw,  but  we  are  not  quite  done, 
since  we  need  this  result  for  Cr,  which  includes  the  equality  axioms: 

EQ1,  (T  =  T)  (reflexivity), 

EQ2.  (S  =  T)  (T  =  S)  (commutativity), 

EQ3.  ((Ti  =  T2)  A  (T2  =  T3))  =>-  (Ti  =  T3)  (transitivity), 

EQ4,  (5i  =  Ti  A  •  •  •  A  Sn  —  Tn)  =$•  (p(«$i, . . . ,  Sn)  =$►  p(Ti, Tn)),  and 

EQ5.  (Si  =  Ti  A  -  ■  ■  A  Sn  —  Tn)  =>■ 

([Sl\Xl, Sn\Xn]t  =  [Tl\XU  ....  Tn\Xn]t) 

Note  that  the  axiom  schemata  EQ1,  EQ2,  EQ3,  and  EQ5,  when  applied  with 
the  resolution  principle,  ean  only  produce  more  equalities  as  their  results.  Since 
equalities  are  not  formulas  of  £rw,  we  can  focus  on  axiom  schema  EQ4,  which 
can  produce  £rw  formulas.  We  must  show  that  any  application  of  an  EQ4  axiom, 
in  the  context  of  a  proof  in  C=  using  assumptions  T  U  R  U  W,  can  be  simulated 
in  £rw  by  the  substitution  of  equal  terms  using  an  equality  in  W. 

We  first  assume  that  only  one  (Si,  T%)  pair  in  the  axiom  is  not  identical;  that  is, 
we  consider  only  EQ4  axioms  of  this  form  (EQ4'): 

(5i  =  Si  A  •  •  •  Sk  =  Tk  A  -  *  •  A  Sn  =  Sn) 

(p[S 1j  •  •  • )  &hi  •  ■  •  j  &n)  ^  P(&h  •  •  ■  >  •  •  • ,  Bn)) 
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Any  other  EQ4  axiom  application  can  be  simulated  by  repeated  application  of 
this  form  and  use  of  EQ1,  so  there  is  no  loss  of  generality.  Note  that  in  order 
for  this  axiom  to  be  applied  fully  and  produce  an  £rw  formula,  there  must  be  a 
proof  of  Sk  =  7*.  Note  further  that  this  proof  can  use  only  the  equality  axioms 
and  equalities  in  W,  since  all  “premises”  of  equality  axioms  are  equalities.  We 
propose  the  following  induction  hypothesis: 

If  either  Sk  =  7*  or  7*  =  Sk  has  a  proof  of  fewer  than  n  steps,  then 
the  application  of  EQ4'  can  be  simulated  in  £rw- 

In  the  base  case,  a  single  step  proof,  either  Sk  and  Tk  are  identical  (an  application 
of  EQ1),  in  which  case  EQ4'  produces  a  trivial  result,  or  the  formula  Sk  =  Tk  (or 
Tk  =  Sk)  is  in  W,  in  which  case  the  result  of  EQ4'  is  the  same  as  that  of  a  simple 
£rw  substitution  using  that  equality. 

For  the  induction  step,  we  assume  that  either  Sk  =  Tk  or  Tk  =  Sk  has  a  proof 
of  n  steps,  and  we  have  three  cases,  depending  on  whether  that  proof  ends  with  an 
application  of  EQ2,  EQ3,  or  EQ5. 

•  Case:  The  last  proof  step  is  an  application  of  EQ2  (commutativity).  In  this 
case,  either  Sk  =  Tk  or  Tk  =  Sk  has  a  proof  shorter  than  n  steps,  so  the 
induction  hypothesis  gives  the  required  result. 

•  Case:  The  last  proof  step  is  an  application  ofEQ3  (transitivity).  There  must 
be  proofs  shorter  than  n  of  Sk  =  U  and  U  =  Tk  (for  some  U ).  We  can  apply 
EQ4'  using  each  of  these  two  equalities  in  sequence  to  get  the  same  result, 
so  by  the  induction  hypothesis,  this  result  is  provable  in  £rw- 

•  Case:  The  last  proof  step  is  an  application  of  EQ5.  Without  loss  of  gener¬ 
ality,  assume  EQ5  is  only  used  with  n  =  1;  that  is,  in  the  following  form: 

(Si  =  Ti)  =»  ([Si\Xi]t  =  [TiYXiJt) 

(We  can  simulate  the  general  case  by  a  sequence  of  applications  of  EQ5  and 
EQ4'.)  If  either  Si  =  T\  or  Ti  =  Si  is  an  equality  in  W,  then  this  appli¬ 
cation  of  EQ5  and  EQ4'  yields  the  same  result  as  a  simple  £rw  substitution 
using  that  equality.  If  Si  =  7i  is  the  result  of  EQ1  (so  Sy  is  identical  to  7\), 
then  EQ5  and  EQ4'  produce  a  trivial  result.  If  Si  =  Ti  is  the  result  of  EQ3, 
then  just  as  in  the  EQ3  case  we  can  simulate  the  result  of  EQ5  and  EQ4'  by 
a  series  of  two  applications  of  EQ5  and  EQ4'.  Therefore,  the  application  of 
EQ4'  following  EQ5  can  always  be  simulated  in  £rw- 
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The  induction  is  complete,  so  it  follows  that  the  equality  axioms  can  be  safely 
added  without  compromising  the  completeness  of  £rw  with  respect  to  Cr.  This 
concludes  the  proof  of  Theorem  2.1.  ■ 
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Appendix  B 

Logics  and  Protocol  Analyses 


This  Appendix  contains  the  main  Revere  specifications  for  BAN,  AUTLOG, 
Kailar’s  accountability  logic,  and  RV,  as  well  as  sample  protocol  specifications 
and  analyses. 


B.l  BAN 


First,  the  BAN  logic,  protocol  specifications,  and  analysis  results. 

LOGIC  BAM; 

REWRITES 

comma_commutative : 

comma  (?X,  ?Y)  =  comma (?y,  ?x) 
comma_associative_l : 

comma (comma ( ?X,  ?Y)  ,  ?Z)  =  comma(?X,  cQmma(?Y,  ?Z) ) 
comma^associative_2 : 

comma (?X,  comma (?Y,  ?Z) )  =  comma (comma ( ?X,  ?Y)  ,  ?Z) 
shared^key^commut at ive : 

shared^key ( ?K,  ?Q,  ?R)  =  sharedjtey  ( ?K,  ?R,  ?Q) 
secret^commutative j 

secret ( ?Y#  ?Q,  ?R)  =  secret (?Y,  ?R,  ?Q) 
distinct_commutative ; 

distinct ( ?P,  ?Q)  =  distinct ( ?Q,  ?P) 

S -RULES 

message_meaning_shared : 

believes ( ?P,  sharedjtey  ( ?K,  ?Q,  ?P) ) 
sees ( ?P,  encrypt (?X,  ?K,  ?R) ) 
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distinct (?P,  ?R) 


believes (?P,  said(?Q,  ?X) ) 

message_meaning_public : 

believes (?P,  public_key ( ?K1 ,  ?Q) ) 
sees ( ?P,  encrypt (?X,  ?K2 ,  ?R) ) 
inv ( ?K1 ,  ?K2) 
distinct (?P,  ?R) 


believes (?P,  said(?Q,  ?X) ) 

message_meaning_secret : 

believes (?P#  secret (?Y,  ?Q,  ?P) ) 
sees(?P,  combine (?X,  ?Y) ) 


believes (?P,  said(?Q,  ?X) ) 

nonce_verif ication_l ; 

believes (?P,  said(?Q,  ?X) ) 
believes ( ?P,  fresh ( ?X) ) 


believes (?P#  believes (?Q,  ?X)  ) 
jurisdiction: 

believes (?P,  controls (?Q,  ?X) ) 
believes (?P,  believes (?Q,  ?X) ) 


believes (?P,  ?X) 
extract__shared : 

believes (?P,  sharedjcey ( ?K,  ?Q,  ?P) ) 
sees(?P,  encrypt (?X,  ?K,  ?R) ) 
distinct (?P,  ?R) 


sees ( ?P,  ?X) 

extract __public_l : 

believes ( ?P,  public_key ( ?K,  ?P)  ) 
sees(?P,  encrypt (?X,  ?K,  ?R) ) 


sees ( ?P,  ?X) 


extract__public_2 : 

believes (?P,  public_key (?K1,  ?Q) ) 
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sees (?P,  encrypt (?X,  ?K2,  ?R) ) 
inv ( ?K1 ,  ?K2) 
distinct (?P,  ?R) 


sees ( ?P,  ?X) 

extract_coinbine : 

sees (?P,  combine (?X,  ?Y) ) 


sees ( ?P,  ?X) 

extract^_comma_2 : 

sees(?P,  comma (?X,  ?Y) ) 

sees (?P,  ?X) 

extract_comma_3 s 

believes (?P,  said(?Q,  comma ( ?X,  ?Y) ) ) 


believes (?P,  said(?Q,  ?X) ) 


extract^comma^_4 : 

believes (?P,  believes (?Q,  comma (?X,  ?Y) ) ) 


believes (?P,  believes (?Q,  ?X) ) 
mm_nv_l s 

believes (?P,  fresh(?K)) 
sees(?P,  encrypt (?X,  ?K,  ?R) ) 
distinct (?P,  ?R) 

believes(?P,  shared^key (?K,  ?Q,  ?P) ) 
believes (?P,  believes (?Q,  ?X) ) 
mm_nv_2 ; 

believes ( ?P,  fresh (?Y)) 
sees ( ?P,  combine (?X,  ?Y) ) 
believes (?P,  secret (?Y,  ?Q,  ?P) ) 


believes (?P,  believes (?Q,  ?X) ) 
O'- RULES 

fresh_extends_l : 

believes (?P,  fresh (?X) ) 
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believes (?P#  fresh (comma ( ?X,  ?Y) ) ) 

f resh_extends_2 : 

believes ( ?P,  fresh ( ?K) ) 


believes (?P,  fresh  (shared__key  ( ?K,  ?Q,  ?R)  )  ) 

f  resh_extends_J3 : 

believes ( ?P,  fresh ( ?K) ) 


believes (?P,  fresh (public_key ( ?K,  ?Q) ) ) 

f resh_extends_4 : 

believes ( ?P,  fresh ( ?Y) ) 


believes (?P,  fresh ( secret ( ?Y,  ?Q,  ?R) ) ) 

f resh_extends_5 : 

believes ( ?P,  fresh ( ?Y) ) 


believes ( ?P,  fresh (combine ( ?X,  ?Y) ) ) 

f resh_extends_6 : 

believes ( ?P,  fresh ( ?K) ) 


believes (?P#  fresh (encrypt (?X,  ?K,  ?R) ) ) 

f  resh__extends_7 : 

believes ( ?P,  fresh ( ?X) ) 


believes (?P,  fresh (encrypt ( ?X,  ?K,  ?R) ) ) 

f resh_extends_8 : 

believes ( ?P,  fresh ( ?X) ) 


believes ( ?P,  fresh (combine ( ?X,  ?Y) ) ) 


END; 


PROTOCOL  Kerberos_l;  //  Logic:  BAN 
VARIABLES 

A,  B,  S;  Principal; 

Kab,  Kas,  Kbs:  SKey; 

Ta,  Ts:  Field; 
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ASSUMPTIONS 

believes (A, 
believes (B, 
believes (S, 
believes (S, 
believes (S, 
believes (A, 
believes (B, 
believes (a, 
believes (B, 
believes (A, 
believes (B, 
distinct (A, 
distinct (A, 
distinct (B, 


shared_key (Kas,  S,  A) ) ; 
shar ed_key ( Kbs ,  S ,  B )  )  ; 
shared_key (Kas,  A,  S)  )  ; 
shar ed_key ( Kbs ,  B,  S) ) ; 
shared_key (Kab,  A,  B) ) ; 
controls (S,  shared_key (?K, 
controls (S ,  shared_key (?K, 
fresh (Ts) ) ; 
fresh (Ts) ) ; 
fresh (Ta) ) ; 
fresh (Ta) ) ; 

s) ; 

B)  ; 

S)  ; 


A, 

A, 


B) )  )  ; 
B)  )  )  ; 


MESSAGES 

1.  S  ->  A:  encrypt ([Ts,  shared_key ( Kab ,  A,  B) ,  encrypt ( [Ts, 

shar ed_key (Kab,  A,  B) ] ,  Kbs,  S) ] ,  Kas,  S) ; 

2.  A  ->  B:  [encrypt ( [Ts,  shar ed_key (Kab,  A,  B) ] ,  Kbs,  S) , 

encrypt ( [Ta,  sharedjcey (Kab,  A,  B) ] ,  Kab,  A) ] ; 

3.  B  ->  A:  encrypt ( [Ta,  shar ed_key (Kab,  A,  B) ] ,  Kab,  B) ; 


GOALS 

believes (A,  shared_key (Kab,  A,  B) ) ; 

believes (B,  shared_key (Kab,  A,  B) ) ; 

believes (B,  believes(A,  shared_key ( Kab ,  A,  B) ) ) ; 

believes(A,  believes(B,  shar ed_key (Kab,  A,  B) ) ) ; 


END; 


Final  theonry  representation  (size  61)  : 
believes (A,  believes (B,  Ta) ) 

believes (A,  believes (B,  [Ta,  shar ed_key (Kab,  A,  B) ] ) ) 
believes (A,  believes (B,  shar ed_key ( Kab ,  A,  B) ) ) 
believes (A,  believes (S,  Ts) ) 

believes(A,  believes (S,  [Ts,  encrypt ([Ts,  shar ed_key (Kab,  A, 
B)  ]  ,  Kbs,  S)  ,  shared__key  (Kab,  A,  B)  ]  )  ) 
believes (A,  believes(S,  [encrypt ( [Ts ,  shared_key ( Kab ,  A, 

B) ] ,  Kbs,  S) ,  shared^key (Kab,  A,  B) ] ) ) 
believes (A,  believes (S,  encrypt ( [Ts,  shared_key (Kab,  A,  B) ] , 
Kbs,  S) ) ) 

believes (A,  believes (S,  shar ed_key ( Kab ,  A,  B) ) ) 
believes (A,  controls (S,  shared_key ( ?CAN0 ,  A,  B) ) ) 
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believes (A,  fresh (Ta) ) 
believes (A,  fresh (Ts) ) 
believes (A,  said(B,  Ta) ) 

believes(A,  said(B,  [Ta,  shared_key (Kab,  A,  B) ] ) ) 
believes  (A,  said(B,  shared__key  (Kab,  A,  B)  )  ) 
believes (A,  said(S,  Ts) ) 

believes (A,  said(S,  [Ts,  encrypt ([Ts,  shared_key (Kab,  A, 

B)  ]  ,  Kbs,  S) ,  shared_key (Kab,  A,  B) ] ) ) 
believes (A,  said(S,  [encrypt ( [Ts,  shared_key (Kab,  A,  B) ] , 
Kbs,  S) ,  shared_key (Kab,  A,  B) ] ) ) 
believes  (A,  said(S,  encrypt  ([Ts,  shared__key  (Kab,  A,  B)  ]  , 
Kbs,  S))) 

believes(A,  said(S,  shared_key (Kab,  A,  B) ) ) 
believes  (A,  shared_key  (Kab,  A,  B)) 
believes (A,  shared_key (Kas ,  A,  S) ) 
believes (B,  believes (A,  Ta) ) 

believes (B,  believes (A,  [Ta,  shared_key (Kab,  A,  B) ] ) ) 
believes (B,  believes (A,  shared_key (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Ts) ) 

believes(B,  believes(S,  [Ts,  shared_key ( Kab ,  A,  B) ] ) ) 
believes (B,  believes (S,  shared_key (Kab,  A,  B) ) ) 
believes (B,  controls (S,  shared„key ( ?CAN0 ,  A,  B) ) ) 
believes (B,  fresh (Ta) ) 
believes (B,  fresh (Ts) ) 
believes (B,  said (A,  Ta) ) 

believes (B,  said (A,  [Ta,  sharedjcey (Kab,  A,  B) ] ) ) 
believes(B,  said(A,  shared_key (Kab,  A,  B) ) ) 
believes (B,  said(S,  Ts) ) 

believes (B,  said(S,  [Ts,  shared_key (Kab,  A,  B) ] ) ) 

believes (B,  said (S,  shared_key (Kab,  A,  B) ) ) 

believes (B,  shared_key (Kab,  A,  B) ) 

believes(B,  shared_key (Kbs ,  B,  S) ) 

believes(S,  shared_key (Kab,  A,  B) ) 

believes(S,  shared_key ( Kas ,  A,  S) ) 

believes(S,  shared__key  (Kbs,  B,  S)  ) 

distinct (A,  B) 

distinct (A,  S) 

distinct (B,  S) 

sees (A,  Ta) 

sees (A,  Ts) 

sees (A,  [Ta,  shared_key (Kab,  A,  B) ] ) 

sees (A,  [Ts,  encrypt ([Ts,  shared_key (Kab,  A,  B) ] ,  Kbs,  S) , 
shared_key (Kab,  A,  B) ) ) 

sees (A,  [encrypt ( [Ts,  shared„key (Kab,  A,  B) ] ,  Kbs,  S) , 
shared_key (Kab,  A,  B) ] ) 
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sees (A,  encrypt ( [Ta,  sharedJcey ( Kab ,  A,  B) ] ,  Kab,  B) ) 
sees (A,  encrypt ( [Ts,  encrypt ( [Ts,  shared_key (Kab,  A,  B) ] , 
Kbs,  S) ,  shared_key (Kab,  A,  B) ] ,  Kas,  S) ) 
sees (A,  encrypt ([Ts,  shared_key (Kab,  A,  B) ] ,  Kbs,  S) ) 
sees (A,  sharedJcey (Kab,  A,  B) ) 
sees(B,  Ta) 
sees(B,  Ts) 

sees (B,  [Ta,  shared_key (Kab,  A,  B) ] ) 
sees (B,  [Ts,  sharedJcey (Kab,  A,  B) ] ) 

sees (B,  [encrypt ( [Ta,  shared_key ( Kab ,  A,  B) ] ,  Kab,  A), 
encrypt ([Ts,  shared_key (Kab,  A,  B) ] ,  Kbs,  S) ] ) 
sees(B,  encrypt ([Ta,  shared_key (Kab,  A,  B) ] ,  Kab,  A)) 
sees(B,  encrypt ( [Ts,  shared_key ( Kab ,  A,  B) ] ,  Kbs,  S) ) 
sees(B,  sharedJcey (Kab,  A,  B) ) 
critical  properties  for  this  theory: 
believes (A,  believes (B,  Ta) ) 

believes (A,  believes (B,  shared_key (Kab,  A,  B) ) ) 
believes (A,  believes (S,  Ts) ) 

believes (A,  believes (S,  encrypt ( [Ts,  sharedJcey (Kab,  A,  B) ] , 
Kbs ,  S) ) ) 

believes (A,  believes (S,  sharedJcey (Kab,  A,  B) ) ) 

believes (A,  said(B,  Ta) ) 

believes (A,  said(S,  Ts) ) 

believes (A,  sharedJcey (Kab,  A,  B) ) 

believes (A,  sharedJcey ( Kas ,  A,  S) ) 

believes (B,  believes (A,  Ta) ) 

believes (B,  believes (A,  sharedJcey (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Ts) ) 

believes(B,  believes(S,  sharedJcey ( Kab ,  A,  B) ) ) 

believes(B,  said(A,  Ta) ) 

believes (B,  said(S,  Ts) ) 

believes (B,  sharedJcey ( Kab ,  A,  B) ) 

believes(B,  sharedJcey (Kbs,  B,  S) ) 

desired  property:  believes (A,  sharedJcey (Kab,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  sharedJcey (Kab,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  sharedJcey (Kab,  A, 

B))) 
is  TRUE 

desired  property:  believes (A,  believes (B,  sharedJcey (Kab,  A, 

B))  ) 
is  TRUE 
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PROTOCOL  Kerberos_2;  //  Logic:  BAN 
VARIABLES 

A,  B,  S:  Principal; 

Kab,  Kas,  Kbs :  SKey; 

Ta,  Ts:  Field; 


ASSUMPTIONS 

believes (A, 
believes (B, 
believes (S, 
believes (S, 
believes (S, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
distinct (A, 
distinct (A, 
distinct (B, 


shared_key (Kas,  S,  A)); 

shar ed_key ( Kbs ,  S ,  B ) ) ; 

shared_key ( Kas ,  A ,  S )  )  ; 

shar ed_key ( Kbs ,  B ,  S )  )  ; 

shar ed_key (Kab,  A,  B) ) ; 

controls (S,  shared_key ( ?K,  A,  B) ) ) ; 

controls(S,  shared_key (?K,  A,  B)  )  )  ; 

fresh (Ts) ) ; 

fresh (Ts) ) ; 

fresh (Ta) ) ; 

fresh (Ta) ) ; 

S)  ; 

B)  ; 

S)  ; 


MESSAGES 

1.  ?  ->  A:  encirypt  (  [Ts,  shared_key  (Kab,  A,  B)  ,  encrypt([Ts, 

shar ed_key (Kab,  A,  B) ] ,  Kbs,  S)],  Kas,  S) ; 

2.  ?  ->  B;  [encrypt ( [Ts,  shar ed_key (Kab,  A,  B) ] ,  Kbs,  S) , 

encrypt ( [Ta,  shared_key (Kab,  A,  B) ] ,  Kab,  A) ] ; 


GOALS 

believes (A, 
believes (B, 
believes (B, 
believes (A, 


shar ed_key (Kab,  A,  B) ) ; 
shared_key (Kab,  A,  B) ) ; 
believes (A,  shared_key (Kab, 
believes (B,  shared_key (Kab, 


A, 

A, 


B))); 

B))); 


END; 

Final  theory  representation  (size  52)  [omitted] 

critical  properties  for  this  theory: 
believes (A,  believes (S,  Ts) ) 

believes (A,  believes (S,  encrypt ([Ts,  shar ed_key (Kab,  A,  B) ] , 
Kbs,  S) ) ) 

believes(A,  believes(S,  shar ed_key (Kab,  A,  B) ) ) 
believes (A,  said(S,  Ts) ) 
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believes (A,  shared_key (Kab,  A,  B) ) 
believes(A,  shared_key ( Kas ,  A,  S) ) 
believes (B,  believes (A,  Ta) ) 

believes (B,  believes (A,  shared^key (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Ts)) 

believes (B,  believes (S,  shared_key (Kab,  A,  B) ) ) 

believes (B,  said (A,  Ta) ) 

believes (B,  said(S,  Ts) ) 

believes (B,  shared_key (Kab,  A,  B) ) 

believes (B,  shared_key ( Kbs ,  B,  S)  ) 

desired  property:  believes (A,  shared^key (Kab,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  shared_key (Kab,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  shared_key ( Kab ,  A, 

B) )  ) 

is  TRUE 

desired  property:  believes (A,  believes (B,  shared_key ( Kab ,  A, 

B)  )  ) 

is  FALSE 

//  - - 

PROTOCOL  Andrew_RPC_l ;  //  Logic:  BAN 

VARIABLES 

A,  B:  Principal; 

Kab,  Kab':  SKey; 

Na,  Nb,  Nb' :  Field; 

ASSUMPTIONS 

believes (A,  shared_key (Kab,  A,  B) ) ; 

believes (B,  shared_key (Kab,  A,  B) ) ; 

believes (A,  controls (B,  shared_key ( ?K,  A,  B) ) ) ; 

believes (B,  shared_key ( Kab ' ,  A,  B) ) ; 

believes (A,  fresh (Na) ) ; 

believes (B,  fresh (Nb) ) ; 

believes (B,  fresh(Nb')); 

distinct (A,  B) ; 

MESSAGES 

1,  ?  ->  B :  encrypt (Na,  Kab,  A) ; 

2.  ?  ->  A:  encrypt ( [Na,  Nb] ,  Kab,  B) ; 

3.  ?  ->  B:  encrypt (Nb,  Kab,  A) ; 

4,  ?  ->  A:  encrypt ( [shared_key (Kab' ,  A,  B) ,  Nb'],  Kab,  B) ; 
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GOALS 

believes(B,  shared__key  ( Kab '  ,  A,  B)  )  ; 

believes (A,  said(B,  [shared_key (Kab' ,  A#  B)  ,  Nb ' ] ) ) ; 

believes (B,  believes (A,  Nb) ) ; 

believes (A,  believes (B,  [Na,  Nb] ) ) ; 

believes (A,  shared__key  (Kab' ,  A,  B)  ) ; 

believes (A,  believes (B,  shared_key (Kab '  ,  A,  B) ) ) ; 

believes (B,  believes (A,  shared_key (Kab' ,  A,  B) ) ) ; 

END; 

Final  theory  representation  (size  32) :  [omitted] 

critical  properties  for  this  theory: 
believes (A,  believes (B,  Na) ) 
believes (A,  believes (B,  Nb) ) 
believes(A,  said(B,  Na) ) 
believes (A,  said(B,  Nb) ) 
believes (A,  said(B,  Nb')) 
believes (B,  believes (A,  Nb) ) 
believes (B ,  said(A,  Na) ) 
believes (B ,  said (A,  Nb) ) 

desired  property:  believes(B,  shared_key (Kab' ,  A,  B) ) 
is  TRUE 

desired  property;  believes(A,  said(B,  [shared_key (Kab' ,  A,  B)  , 
Nb'])) 
is  TRUE 

desired  property:  believes(B,  believes(A,  Nb) ) 
is  TRUE 

desired  property:  believes (A,  believes(B,  [Na,  Nb] ) ) 
is  TRUE 

desired  property:  believes(A,  shared^key ( Kab ' ,  A,  B) ) 
is  FALSE 

desired  property;  believes(A,  believes(B,  shared_key {Kab' ,  A, 
B))) 

is  FALSE 

desired  property:  believes(B,  believes(A,  shared_key (Kab' #  A, 
B))) 

IS  FALSE 

//  — - - - - — - - - 

PROTOCOL  Andrew_RPC_2 ?  //  Logic;  BAN 

VARIABLES 

A,  B:  Principal; 
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Kab,  Kab':  £Key; 

Na,  Nb,  Nb':  Field; 

ASSUMPTIONS 

believes (A,  shared„key (Kab,  A,  B) ) ; 
believes (B,  shared_key (Kab,  A,  B) ) ; 
believes(A,  eontrols(B,  shared_key ( ?K,  A,  B)  )  )  ; 
believes (B,  shared_key (Kab' ,  A,  B) ) ; 
believes (A,  fresh (Na) ) ; 
believes (B,  fresh (Nb) ) ; 
believes (B,  fresh (Nb' ) ) ; 
distinct (A,  B)  ; 

MESSAGES 

1.  ?  ->  B :  encrypt (Na,  Kab,  A); 

2.  ?  ->  A:  encrypt ([Na,  Nb] ,  Kab,  B) ; 

3.  ?  ->  B:  encrypt (Nb,  Kab,  A) ; 

4.  ?  ->  A:  encrypt ( [ share d_key ( Kab ' ,  A,  B) ,  Nb' ,  Na] ,  Kab, 


GOALS 

believes (B,  sharedjcey (Kab' ,  A,  B) ) ; 

believes (A,  shar ed^key ( Kab ' ,  A,  B) ) ; 

believes (A,  believes (B,  shared^key (Kab' ,  A,  B) ) ) ; 

believes (B,  believes(A,  shared_key (Kab' ,  A,  B) ) ) ; 

END; 

Final  theory  representation  (size  39) :  [omitted] 

critical  properties  for  this  theory: 
believes (A,  believes (B,  Na) ) 
believes (A,  believes (B,  Nb) ) 
believes (A,  believes (B,  Nb')) 

believes (A,  believes (B,  shared_key (Kab' ,  A,  B) ) ) 

believes (A,  said(B,  Na) ) 

believes (A,  said(B,  Nb) ) 

believes (A,  said(B,  Nb')) 

believes(A,  shared_key ( Kab ' ,  A,  B) ) 

believes (B,  believes (A,  Nb) ) 

believes (B,  said(A,  Na) ) 

believes (B,  said (A,  Nb) ) 

desired  property;  believes (B,  shared_key ( Kab ' ,  A,  B) ) 
is  TRUE 
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desired  property;  believes(A,  shared_key (Kab' ,  A,  B) ) 
is  TRUE 

desired  property:  believes (A,  believes(B,  shared_key (Kab' ,  A, 
B)  )  ) 
is  TRUE 

desired  property:  believes(B,  believes (A,  shared_key ( Kab A, 
B)  )  ) 

IS  FALSE 


//  - 

PROTOCOL  Andrew_RPC_3 ;  //  Logic:  BAN 


VARIABLES 

A,  B:  Principal; 
Kab,  Kab':  SKey; 
Na;  Field; 


ASSUMPTIONS 

believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (B, 
distinct (A, 
believes (B, 


shared_key (Kab,  A,  B)  )  ; 
shared_key (Kab,  A,  B) ) ; 
controls (B,  shared_key ( ?K,  A, 
shared^key (Kab' ,  A,  B) ) ; 
fresh (Na) ) ; 
fresh (Nb) ) ; 
fresh (Nb' ) ) ; 

B)  ; 

fresh (Kab' ) ) ; 


B)  )  )  ; 


MESSAGES 

1.  ?  ->  A:  encrypt ( [Na,  shared_key (Kab' ,  A,  B) ] ,  Kab,  B) ; 

2.  ?  ->  B:  encrypt (shared^key (Kab' ,  A,  B) ,  Kab',  A); 

GOALS 

believes(B,  shared__key  (Kab '  ,  A,  B)  )  ; 

believes (A,  shared_key (Kab' ,  A,  B) ) ; 

believes (A,  believes (B,  shared_key (Kab' ,  A,  B) ) ) ; 

believes (B,  believes (A,  shared_key ( Kab ' ,  A,  B) ) ) ; 


END; 

Final  theory  representation  (size  24) :  [omitted] 

critical  properties  for  this  theory; 
believes (A,  believes (B,  Na) ) 

believes  (A,  believes  (B,  shared__key  (Kab' ,  A,  B)  ) ) 
believes (A,  said(B,  Na) ) 
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believes  (A,  shared_key  (Kab' ,  A,  B)  ) 
believes(B,  believes(A,  shared_key (Kab' ,  A,  B) )  ) 

desired  property:  believes (B,  shared_key (Kab' ,  A,  B) ) 
is  TRUE 

desired  property:  believes (A,  shared_key (Kab' ,  A,  B)  ) 
is  TRUE 

desired  property:  believes (A,  believes (B,  shared_key (Kab' ,  A, 
B)  )  ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  shared_key (Kab' ,  A, 
B)  )  ) 
is  TRUE 

PROTOCOL  Needham_Schroeder_l ;  //  Logic;  BAN 

VARIABLES 

A,  B,  S:  Principal; 

Ka,  Kb,  Ks':  PKey; 

Na,  Nb:  Field; 


ASSUMPTIONS 

believes (A, 
believes (A, 
believes (B, 
believes (B, 
believes (S, 
believes (S, 
believes (S, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (A, 
believes (B, 
distinct (A, 
distinct (A, 
distinct (B, 
inv ( Ks ,  Ks' 


public_key (Ka,  A) ) ; 
public^key (Ks ,  S) ) ; 
publ i c_key ( Kb ,  B) ) ; 
public_key (Ks,  3) )  ; 
public_key (Ka,  A) ) ; 
public_key (Kb,  B) ) ; 
publ i c Jcey ( Ks ,  S ) ) ; 
controls (S,  public Jcey ( ?K, 
controls (S,  public^key ( ?K, 
fresh (Na) ) ; 
fresh (Nb) ) ; 
secret (Na,  A,  B) ) ; 
secret (Nb,  A,  B) ) ; 
fresh  (public_key  (Kb,  B)  )  )  ; 
fresh (publicjtey (Ka,  A)  )  )  ; 
B)  ; 

S)  ; 

S)  / 


B))); 
A) )  )  ; 


MESSAGES 

1,  ?  ->  A;  encrypt (public_key (Kb,  B) ,  Ks ' ,  S)  ; 

2.  ?  ->  B:  encrypt (Na,  Kb,  A); 
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3.  ?  ->  B:  encrypt  (public__key  (Ka,  A),  Ks '  ,  S)  ; 

4.  ?  ->  A:  encrypt (combine (secret (Nb,  A,  B)  ,  Na) ,  Ka,  B) ; 

5.  ?  ->  B:  encrypt (combine (secret (Na,  A,  B) ,  Nb) ,  Kb,  A); 


GOALS 

believes (A,  public_key (Kb,  B) ) ; 
believes(B,  public_key (Ka,  A)); 
believes (A,  believes (B,  secret (Nb,  A,  B)  )  )  ; 
believes (B,  believes (A,  secret (Na,  A,  B) ) ) ; 


END; 


Final  theory  representation  (size  41) :  [omitted] 

critical  properties  for  this  theory: 

believes (A,  believes (B,  secret (Nb,  A,  B) ) ) 
believes (A,  believes (S,  public_key (Kb,  B) ) ) 
believes (A,  public_key (Kb,  B) ) 
believes (B,  believes (A,  secret (Na,  A,  B) ) ) 
believes (B,  believes (S,  public_key (Ka,  A))) 
believes(B,  public_key (Ka,  A)) 


desired  property:  believes(A,  public^key (Kb,  B) ) 
is  TRUE 

desired  property:  believes(B,  public_key (Ka,  A)) 
is  TRUE 

desired  property;  believesfA,  believes(B,  secret(Nb,  A,  B) ) ) 
is  TRUE 

desired  property:  believes(B,  believes(A,  secret (Na,  A,  B) ) ) 
is  TRUE 


n - 

PROTOCOL  Needham_Schroeder_2 ;  //  Logic:  BAN 

VARIABLES 

A,  B,  S:  Principal; 

Ka,  Kb,  Ks':  PKey; 

Na,  Nb,  Ts:  Field; 


ASSUMPTIONS 

believes (A,  public^key (Ka,  A)) 
believes(A,  public_key (Ks,  S) ) 
believes(B,  public_key (Kb,  B) ) 
believes(B,  public_key  (Ks,  jS)  ) 
believes(S,  public_key (Ka,  A)) 
believes(S,  public__key  (Kb,  B)  ) 
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believes(S/  public_key (Ks ,  S) ) ; 

believes(A,  controls(S,  public_key ( ?K,  B) ) ) ; 

believes (B,  controls (S,  public_key ( ?K,  A))); 

believes (A,  fresh (Na) ) ; 

believes (B,  fresh (Nb) ) ; 

believes (A,  fresh (Ts ) ) ; 

believes (B,  fresh (Ts) ) ; 

believes (A,  secret (Na,  A,  B) ) ; 

believes (B,  secret (Nb,  A,  B) ) ; 

distinct (A,  B) ; 

distinct (A,  S) ; 

distinct (B,  S) ; 

inv (Ks ,  Ks'); 

MESSAGES 

1.  ?  ->  A:  encrypt ( [public_key (Kb,  B) ,  Ts] ,  Ks',  S) ? 

2.  ?  ->  B;  encrypt (Na,  Kb,  A); 

3.  ?  ->  B:  encrypt ( [public_key (Ka,  A),  Ts]  ,  Ks',  S) ; 

4.  ?  ->  A;  encrypt (combine (secret (Nb,  A,  B) ,  Na) ,  Ka, 

5.  ?  ->  B:  encrypt (combine (secret (Na,  A,  B) ,  Nb) ,  Kb, 

GOALS 

believes (A,  public^key (Kb,  B) ) ; 
believes (B,  public^key (Ka,  A)); 
believes (A,  believes (B,  secret (Nb,  A,  B) ) ) ; 
believes (B,  believes (A,  secret (Na,  A,  B) ) ) ; 

END; 

Final  theory  representation  (size  53) :  [omitted] 

critical  properties  for  this  theory: 

believes (A,  believes (B,  secret (Nb,  A,  B) ) ) 

believes (A,  believes (S,  Ts) ) 

believes (A,  believes (S,  publicjcey  (Kb,  B) ) ) 

believes (A,  public_key (Kb,  B) ) 

believes (A,  said(S,  Ts) ) 

believes (B,  believes (A,  secret (Na,  A,  B) ) ) 
believes (B,  believes (S,  Ts) ) 
believes(B,  believes(S,  publicjcey (Ka,  A))) 
believes (B,  publ i c  Jcey ( Ka ,  A)) 
believes (B,  said (S,  Ts) ) 

desired  property;  believes (A,  publicjcey (Kb,  B) ) 
is  TRUE 


PQi  < 
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desired  property:  believes(B,  public_key (Ka,  A)) 
is  TRUE 

desired  property:  believes (A,  believes (B,  secret (Nb,  A,  B) ) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  secret (Na,  A,  B) ) ) 
is  TRUE 

// - 

PROTOCOL  X_509_l;  //  Logic:  BAN 

VARIABLES 

A,  B:  Principal; 

Ka,  Ka ' ,  Kb,  Kb':  PKey; 

Na,  Nb,  Ta,  Tb,  Xa,  Xb,  Ya,  Yb:  Field; 

ASSUMPTIONS 

believes (A,  public_key (Ka,  A) ) ; 
believes(B,  public__key  (Kb,  B)  )  ; 
believes (A,  public_key (Kb,  B) ) ; 
believes (B,  public_key (Ka,  A) )  ; 
believes (A,  fresh (Na) ) ; 
believes (B,  fresh (Nb) ) ; 
believes (A,  fresh (Tb) ) ; 
believes (B,  fresh (Ta) ) ; 
believes (A,  secret (Na,  A,  B) ) ; 
believes (B,  secret (Nb,  A,  B) ) ; 
distinct (A,  B) ? 
inv(Ka,  Ka'); 
inv(Kb,  Kb'); 


MESSAGES 

1,  ?  ->  B:  encrypt ([Ta,  Na,  Xa,  encrypt (Ya,  Kb,  A)],  Ka', 

A)  ; 

2,  ?  ->  A:  encrypt ([Tb,  Nb,  Na,  Xb,  encrypt (Yb,  Ka,  B) ] , 

Kb',  B); 

3,  ?  ->  B:  encrypt (Nb,  Ka',  A) ; 


GOALS 

believes  (A, 
believes (B, 
believes (A, 
believes (B, 


believes (B,  Xb) ) ; 
believes (A,  Xa) ) ; 
believes (B,  Yb) ) ; 
believes (A,  Ya) ) ; 


END; 


Final  theory  representation  (size  69) :  [omitted] 
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critical  properties  for  this  theory: 
believes (A,  believes (B,  Na) ) 
believes (A,  believes (B,  Nb) ) 
believes (A,  believes (B,  Tb) ) 
believes (A,  believes (B,  Xb) ) 

believes (A,  believes (B,  encrypt (Yb,  Ka,  B) ) ) 

believes (A,  said(B,  Na) ) 

believes (A,  said(B,  Nb) ) 

believes (A,  said(B,  Tb) ) 

believes (A,  said(B,  Xb) ) 

believes (B,  believes (A,  Na) ) 

believes (B,  believes (A,  Nb) ) 

believes (B,  believes (A,  Ta)  ) 

believes (B,  believes (A,  Xa) ) 

believes (B,  believes (A,  encrypt (Ya,  Kb,  A))) 

believes (B,  said (A,  Na) ) 

believes (B,  said (A,  Nb) ) 

believes (B,  said(A,  Ta) ) 

believes (B,  said (A,  Xa) ) 

desired  property:  believes (A,  believes (B,  Xb) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  Xa) ) 
is  TRUE 

desired  property;  believes (A,  believes (B,  Yb) ) 
is  FALSE 

desired  property;  believes (B,  believes (A,  Ya) ) 
is  FALSE 

PROTOCOL  X_509_2;  //  Logic:  BAN 

VARIABLES 

A,  B;  Principal; 

Ka,  Ka' ,  Kb,  Kb';  PKey; 

Na,  Nb,  Ta,  Xa,  Xb,  Ya,  Yb:  Field; 

ASSUMPTIONS 

believes (A,  publicjcey (Ka,  A) ) ; 
believes (B,  publicjcey (Kb,  B) ) ; 
believes (A,  public_key (Kb,  B) ) ; 
believes (B,  publie_key (Ka,  A) ) ; 
believes (A,  fresh (Na) ) ; 
believes (B,  fresh (Nb) ) ; 
believes (B,  fresh (Ta) ) ; 
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believes (A#  secret (Na,  A,  B) ) ; 
believes (B,  secret (Nb,  A,  B) ) ; 
distinct (A,  B) ; 
inv(Ka,  Ka'); 
inv(Kb,  Kb'); 

MESSAGES 

1,  ?  ->  B:  encrypt ( [Ta,  Na,  Xa,  encrypt (encrypt ( [Ya,  Ta] , 

Ka',  A)  ,  Kb,  A)  ]  ,  Ka',  A)  ; 

2,  ?  ->  A;  encrypt  ([Nb,  Na,  Xb,  encrypt  (encrypt  (  [Yb,  Na]  , 

Kb',  B),  Ka,  B)],  Kb',  B) ; 

3,  ?  ->  B:  encrypt (Nb,  Ka',  A); 

GOALS 

believes (A,  believes (B,  Xb) ) ; 
believes (B,  believes (A,  Xa) ) ; 
believes (A,  believes (B,  Yb)  )  ; 
believes (B,  believes (A,  Ya) )  ; 

END; 

Final  theory  representation  (size  74) :  [omitted] 

critical  properties  for  this  theory: 
believes (A,  believes (B,  Na) ) 
believes (A,  believes (B,  Nb) ) 
believes (A,  believes (B,  Xb) ) 
believes (A,  believes (B,  Yb) ) 

believes (A,  believes (B,  encrypt (encrypt ( [Na,  Yb] ,  Kb',  B) , 
Ka,  B) ) ) 

believes (A,  said(B,  Na) ) 
believes (A,  said(B,  Nb)  ) 
believes (A,  said(B,  Xb) ) 
believes (A,  said(B,  Yb)  ) 
believes  (B,  believes  (A,  Na)  ) 
believes (B,  believes (A,  Nb) ) 
believes (B,  believes (A,  Ta) ) 
believes (B,  believes (A,  Xa) ) 
believes (B,  believes (A,  Ya) ) 

believes (B,  believes (A,  encrypt (encrypt ( [Ta,  Ya] ,  Ka',  A), 
Kb,  A))) 

believes (B,  said (A,  Na) ) 
believes (B,  said (A,  Nb) ) 
believes (B,  said(A,  Ta) ) 
believes (B,  said (A,  Xa) ) 
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believes (B,  said (A,  Ya) ) 

desired  property:  believes (A,  believes (B,  Xb) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  Xa) ) 
is  TRUE 

desired  property:  believes (A,  believes(B,  Yb) ) 
is  TRUE 

desired  property;  believes (B,  believes (A/  Ya) ) 
is  TRUE 

//  — — - - -- - —  - 

PROTOCOL  Wide__Mouth_Frog_l ;  //  Logic:  BAN 

VARIABLES 

A,  B,  s ;  Principal; 

Kab,  Kat,  Kbt:  SKey; 

Ta,  Ts;  Field; 

ASSUMPTIONS 

believes (A,  shared_key (Kat ,  A,  S) ) ; 
believes(S,  shared_key ( Kat ,  A,  S) ) ; 
believes(B,  sharedjcey (Kbt ,  B,  S) ) ; 
believes(S,  shared_key (Kbt ,  B,  S) ) ; 
believes (A,  shared_key ( Kab ,  A,  B) ) ; 
believes (S,  fresh (Ta) ) ; 
believes (B,  fresh (Ts) ) ; 

believes(S,  controls (A,  sharedjcey ( ?K,  A,  B) ) ) ; 
believes (B,  controls (S,  shared__key  ( ?K,  A,  B)  )  )  ; 
distinct (A,  B) ; 
distinct (A,  S) ; 
distinct (B,  S) ; 

MESSAGES 

1.  ?  ->  S:  encrypt ( [Ta,  shared_key (Kab,  A,  B) ] ,  Kat, 

2,  ?  ->  B;  encrypt  (  [Ts,  shared___key  ( Kab ,  A,  B)  ]  ,  Kbt, 

GOALS 

believes (A,  sharedjtey (Kab,  A,  B) ) ; 

believes (B,  shar  edJcey ( Kab ,  A,  B) ) ; 

believes (B,  believes (A,  shar edjtey (Kab,  A,  B) ) ) ; 

believes (A,  believes (B,  shared_key (Kab,  A,  B) ) ) ; 

END; 


Final  theory  r epr e s en t a t i on  (size  34) :  [omitted] 


<  01 
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critical  properties  for  this  theory: 
believes (B,  believes (S,  Ts) ) 

believes (B,  believes (S,  sharedjtey (Kab,  A,  B) ) ) 
believes(B,  said(S,  Ts) ) 
believes (B,  shared_key (Kab,  A,  B) ) 
believes (S#  believes (A,  Ta) ) 

believes(S,  believes(A,  shared_key (Kab,  A,  B) ) ) 
believes (S,  said (A,  Ta) ) 
believes(S,  shared_key (Kab,  A,  B) ) 


desired  property:  believes (A, 
is  TRUE 


desired  property:  believes (B, 
is  TRUE 

desired  property:  believes (B, 

B)  )  ) 

is  FALSE 

desired  property:  believes (A, 
B))) 

is  FALSE 


sharedjcey (Kab,  A,  B) ) 
ehared_key (Kab,  A,  B) ) 
believes (A,  shared_key (Kab, 

believes (B,  shared_key (Kab, 


A, 


A, 


// - - - 

PROTOCOL  Wide_Mouth__Frog_2 ;  //  Logic:  BAN 

VARIABLES 

A,  &,  S:  Principal; 

Kab,  Kat,  Kbt :  SKey; 

Ta,  Ts:  Field; 


ASSUMPTIONS 

believes (A, 
believes (S, 
believes (B, 
believes (S, 
believes (A, 
believes (S, 
believes (B, 
believes (B, 
B) )  )  )  ; 
believes (B, 
distinct (A, 
distinct (A, 
distinct (B, 


shared„key (Kat , 

A, 

S)  ) 

shared_key ( Kat , 

A, 

S)) 

shared_key ( Kbt , 

B, 

S)  ) 

shared_key ( Kbt , 

B, 

S)  ) 

shared_key ( Kab , 

A, 

B)  ) 

fresh (Ta) ) ; 
fresh (Ts) ) ; 

controls (S,  believes (A,  shared^key ( ?K, 

controls (A,  shared_key ( ?K,  A,  B) ) ) ; 

B); 

S); 

S)  ; 


A, 


MESSAGES 
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1.  ?  ->  S;  encrypt (  [Ta,  shar ed_key (Kab,  A,  B) ] ,  Kat,  A) ; 

2.  ?  ->  B:  encrypt ([Ts,  believes (A,  sharecMtey (Kab,  A,  B)  )  ]  , 

Kbt,  S); 

GOALS 

believes  (A,  shared__key  (Kab,  A,  B)  )  ; 

believes (B,  shared_key ( Kab ,  A,  B) ) ? 

believes (B,  believes (A,  shared_key ( Kab ,  A,  B) ) ) ; 

believes (A,  believes (B,  sharedJkey (Kab,  A,  B) ) ) ; 


END; 


Final  theory  representation  (size  34) :  [omitted] 


critical  properties  for  this  theory: 

believes (B,  believes (A,  shared_key (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Ts) ) 

believes (B,  believes (S,  believes (A,  shared_key (Kab, 


B)  )  )  ) 

believes (B, 
believes (B, 
believes (S, 
believes (S, 
believes (S, 


said(S,  Ts) ) 

shar ed_key ( Kab ,  A ,  B) ) 

believes (A,  Ta) ) 

believes (A,  sharedJkey ( Kab ,  A,  B) ) ) 
said (A,  Ta) ) 


A, 


desired  property;  believes (A,  shared_key (Kab,  A,  B) ) 
is  TRUE 

desired  property;  believes (B,  shared_key (Kab,  A,  B) ) 
is  TRUE 

desired  property;  believes (B,  believes (A,  shar ed_Jkey (Kab,  A, 
B))) 
is  TRUE 

desired  property;  believes (A,  believes (B,  shar  ed__key  ( Kab ,  A, 
B)  )  ) 

is  FALSE 


PROTOCOL  Yahalom_2 ;  //  Logic;  BAN 

VARIABLES 

A,  B,  S:  Principal; 

Kab,  Kas,  Kbs ;  SKey ; 

Ra,  Rb;  Field; 

ASSUMPTIONS 

believes(A,  shar ed^key (Kas,  A,  S) ) ; 
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believes(B,  sharedjtey (Kbs,  B,  S) ) ; 
believes (A,  fresh (Ra) ) ; 
believes (B,  fresh (Rb) ) ; 

believes(A,  controls(S,  shared_key ( ?K,  A,  B) ) ) ; 
believes (B,  controls (S,  shared_key ( ?K,  A,  B) ) ) ; 
distinct (A,  B) ; 
distinct (A,  S) ; 
distinct (B,  S) ; 

MESSAGES 

1.  ?  ->  S:  encrypt ([Ra,  A],  Kbs,  B) ; 

2.  ?  ->  A:  encrypt ( [Ra,  shared_key (Kab,  A,  B) ] ,  Kas,  S) ; 

3.  ?  ->  A:  encrypt ( [Rb,  shared__key (Kab,  A,  B) ] ,  Kbs,  S) ; 

4.  ?  ->  B:  encrypt ([Rb,  shared_key (Kab,  A,  B) ] ,  Kbs,  S) ; 

5.  ?  ->  B:  encrypt ([Rb,  sharedjcey (Kab,  A,  B) ] ,  Kab,  A); 

GOALS 

believes (A,  shared_key (Kab,  A,  B) ) ; 
believes (B,  shared_key (Kab,  A,  B) ) ; 
believes(B,  believes(A,  shared_key ( Kab ,  A,  B) ) ) ; 
believes (A,  believes(B,  shared_key (Kab,  A,  B) ) ) ; 

END; 

Final  theory  representation  (size  40) :  [omitted] 

critical  properties  for  this  theory; 
believes (A,  believes (S,  Ra) ) 

believes (A,  believes (S,  shared_key (Kab,  A,  B) ) ) 
believes (A,  said(S,  Ra) ) 
believes (A,  shared_key (Kab,  A,  B) ) 
believes (B,  believes (A,  Rb) ) 

believes (B,  believes (A,  shared_key (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Rb) ) 

believes (B,  believes (S,  shared_key (Kab,  A,  B) ) ) 

believes (B,  said(A,  Rb) ) 

believes (B,  said(S,  Rb) ) 

believes (B,  shared_key (Kab,  A,  B) ) 

desired  property:  believes (A,  shared_key ( Kab ,  A,  B) ) 
is  TRUE 

desired  property;  believes (B,  sharedjcey ( Kab ,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  believes (A,  sharedjcey (Kab,  A, 
B)  )  ) 
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is  TRUE 

desired  property:  believes(A,  believes(B,  shared_key (Kab,  A, 

B)  )  ) 

is  FALSE 

PROTOCOL  Yahalom_3 ;  //  Logic:  BAN 

VARIABLES 

A,  B,  S:  Principal; 

Kab,  Kas,  Kbs :  SKey; 

Ra,  Rb:  Field; 

ASSUMPTIONS 

believes(A,  shared_key (Kas ,  A,  S) ) ; 
believes (B,  shared_key ( Kbs ,  B,  S)  )  ; 
believes (S,  shared_key (Kas,  A,  S) ) ; 
believes (S,  shared_key (Kbs,  B,  S)  )  ; 
believes(S,  shared_key (Kab,  A,  B) ) ; 
believes (A,  fresh (Ra) ) ; 
believes (B,  fresh (Rb) ) ; 

believes(A,  controls (S,  shared_key ( ?K,  A,  B) ) ) ; 
believes(B,  controls(S,  shared_key ( ?K,  A,  B) ) ) ; 
believesfS,  fresh (shared_key (Kab,  A,  B) ) ) ; 
believes (B,  controls (S,  fresh ( shared_key ( ?K,  A,  B) ) ) ) ; 
believes (B,  controls (A,  believes (S,  fresh ( shared_key ( ?K,  A, 
B))))); 

believes(A,  controls (S,  said(B,  ?N) ) ) ; 
believes (B,  secret (Rb,  A,  B) ) ; 
distinct (A,  B) ; 
distinct (A,  S) ; 
distinct (B,  S)  ; 

MESSAGES 

1 .  ?  ->  S:  encrypt ( [Ra,  Rb] ,  Kbs,  B) ; 

2,  ?  ->  A;  encrypt ( [ shared_key ( Kab ,  A,  B) , 

fresh ( shared_key ( Kab ,  A,  B) ) ,  Ra,  Rb,  said (B,  Ra) ] , 
Kas,  S) ; 

3.  ?  ->  A:  encrypt (shared  Jcey (Kab,  A,  B)  ,  Kbs,  S) ; 

4,  ?  ~>  B :  encrypt ( shared  Jcey (Kab,  A,  B) ,  Kbs ,  S) ; 

5  ,  ?  ->  B :  encrypt  (combine  (  [Rb,  shar edjcey  ( Kab ,  A,  B)  , 

believes (S,  fresh ( shared_key ( Kab ,  A,  B) ) ) ] ,  Rb) ,  Kab, 
A)  ; 

GOALS 

believes (A,  shared_key (Kab,  A,  B) ) ; 
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believes (B,  sharedjcey (Kab,  A,  B)  )  ; 

believes (B,  believes (A,  sharedjcey (Kab,  A,  B) ) ) ; 

believes (A,  believes (B,  Ra) ) ; 

END; 

Final  theory  representation  (size  60) :  [omitted] 

critical  properties  for  this  theory; 
believes (A,  believes (B,  Ra) ) 
believes (A,  believes (S,  Ra) ) 
believes (A,  believes (S,  Rb) ) 

believes (A,  believes (S,  fresh (sharedjcey (Kab,  A,  B) ) ) ) 

believes (A,  believes (S,  said(B,  Ra) ) ) 

believes(A,  believes(S,  sharedjcey ( Kab ,  A,  B) ) ) 

believes (A,  said(B,  Ra) ) 

believes (A,  said(S,  Ra) ) 

believes (A,  said(S,  Rb) ) 

believes (A,  shared_key (Kab,  A,  B) ) 

believes (S,  said(B,  Ra) ) 

believes (S,  said(B,  Rb) ) 

desired  property:  believes (A,  sharedjcey (Kab,  A,  B) ) 
is  TRUE 

desired  property:  believes (B,  sharedjcey (Kab,  A,  B) ) 
is  FALSE 

desired  property;  believes (B,  believes (A,  sharedjcey (Kab,  A, 
B))) 

is  FALSE 

desired  property:  believes (A,  believes (B,  Ra)  ) 
is  TRUE 

//  - - - - - - 

PROTOCOL  YahaloinJ;  //  Logic;  BAN 

VARIABLES 

A,  B,  S:  Principal; 

Kab,  Kas,  Kbs :  SKey; 

Ra,  Rb:  Field; 

ASSUMPTIONS 

believes(A,  sharedjcey (Kas ,  A,  S) ) ; 
believes(B,  sharedjcey (Kbs ,  B,  S) ) ; 
believes(S,  sharedjcey (Kas,  A,  S) ) ; 
believesfS,  sharedjcey (Kbs,  B,  S) ) ; 
believes (S,  sharedjcey (Kab,  A,  B) ) ; 
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believes (A, 
believes (B, 
believes (A, 
believes (B, 
believes (S, 
believes (B, 
believes (B, 
B))))) 
believes  (A, 
believes (B, 
distinct (A, 
distinct (A, 
distinct (B, 


fresh (Ra) ) ; 
fresh (Rb) ) ; 

controls(S,  shared_key ( ?K,  A,  B) ) ) ; 
controls(S,  shared_key ( ?K,  A,  B))); 
fresh  (shared__key  (Kab,  A,  B)  )  )  ; 
controls (S,  fresh (shared Jtey ( ?K,  A,  B) ) ) ) ; 
controls (A,  believes (3,  fresh (shared_key ( ?K,  A, 

controls (S,  said(B,  ?N) ) ) ; 
secret (Rb,  A,  B) ) ; 

B)  ; 

S)  ; 

S)  ; 


MESSAGES 

1.  ?  ->  S:  encrypt ([A,  Ra]  ,  Kbs,  B) ; 

2.  ?  ->  A;  encrypt ( [ shared_key (Kab,  A,  B)  ,  said(B,  Ra) ,  Ra] , 

Kas,  S) ; 

3.  ?  ->  A:  encrypt ( [shared_key (Kab,  A ,  B)  ,  Rb] ,  Kbs,  S) ; 

4.  ?  ->  B:  encrypt ( [shared^key (Kab,  A,  B) ,  Rb] ,  Kbs,  S) ; 

5.  ?  ->  B:  encrypt ([Rb,  shared_key ( Kab ,  A,  B) ] ,  Kab,  A); 


GOALS 

believes (A,  shared^key ( Kab ,  A,  B) ) ; 

believes (B,  shared_key (Kab,  A,  B) ) ; 

believes (B,  believes (A,  shared_key (Kab,  A,  B) ) ) ; 

believes (A,  believes (B,  Ra) ) ; 


END; 


Final  theory  representation  (size  62) :  [omitted] 


critical  properties  for  this  theory: 


Ra)  ) 

Ra)  ) 

said (B,  Ra) ) ) 
shared_key (Kab,  A,  B) ) ) 


believes (A,  believes (B, 
believes (A,  believes (S, 
believes (A,  believes (S, 
believes (A,  believes (S, 
believes (A,  said(B,  Ra) ) 
believes (A,  said(S,  Ra) ) 
believes (A,  shar ed_key ( Kab ,  A,  B) ) 
believes (B,  believes (A,  Rb) ) 

believes (B,  believes (A,  shared_key (Kab,  A,  B) ) ) 
believes (B,  believes (S,  Rb) ) 

believes (B,  believes (3,  shar ed_key ( Kab ,  A,  B) ) ) 
believes (B,  said (A,  Rb) ) 
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believes (B,  said(S,  Rb) ) 
believes (B,  shared_key ( Kab ,  A,  B) ) 
believes (S,  said(B,  A)) 
believes (S,  said(B,  Ra) ) 


desired  property: 
is  TRUE 

desired  property: 
is  TRUE 

desired  property; 
B))) 
is  TRUE 

desired  property: 
is  TRUE 


believes (A, 
believes (B, 
believes (B, 


believes (A, 


shar ed_key ( Kab ,  A,  B) ) 
shar ed_key ( Kab ,  A ,  B) ) 
believes (A,  shar ed_key (Kab, 

believes (B,  Ra) ) 


A, 


B.2  AUTLOG 

AUTLOG,  with  sample  protocol  specifications  and  Revere  analyses: 

LOGIC  AUTLOG; 

REWRITES 

comma^commutative : 

comma (?X#  ?Y)  =  comma (?Y,  ?X) 
comma_associative_l : 

comma ( comma (?X,  ?Y) ,  ?Z)  =  comma(?X,  comma(?Y,  ?Z) ) 
comma_associative_2 : 

comma (?X,  comma (?Y,  ?Z) )  =  comma (comma ( ?X,  ?Y)  ,  ?Z) 
shared_key__commutative : 

shared_key ( ?K,  ?Q,  ?R)  =  shared_key ( ?K,  ?R,  ?Q) 

secret_commutative : 

secret (?Y,  ?Q,  ?R)  =  secret (?Y,  ?R,  ?Q) 

S-RULES 

seeing^list ; 

sees(?p#  comma ( ?X,  ?Y) ) 


sees ( ?P,  ?X) 


list^said: 

believes ( ?P,  said(?Q,  comma (?X,  ?Y) ) ) 


believes (?P,  said(?Q,  ?X) ) 
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list_rec_said : 

believes (?P,  says(?Q,  comma (?X,  ?Y) ) ) 


believes (?P,  says(?Q,  ?X) ) 

nonce_verif ication: 

believes ( ?P,  fresh ( ?X) ) 
believes ( ?P,  said(?Q,  ?X) ) 


believes (?P,  says(?Q,  ?X) ) 
jurisdiction: 

believes (?P,  controls (?Q,  ?X) ) 
believes (?P,  says(?Q,  ?X) ) 


believes (?P,  ?X) 
seeing_shared : 

sees (?P,  shared_key (?K,  ?P,  ?Q) ) 
sees ( ?P,  encrypt (?X,  ?K,  ?B) ) 


sees ( ?P,  ?X) 


auth^shared : 

believes ( ?P,  shared__key  ( ?K,  ?Q,  ?P) ) 
sees ( ?P,  encrypt ( ?X,  ?K,  ?R) ) 
believes (?P,  recognizable ( ?X) ) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?K) ) 

believes (?P,  said(?Q,  encrypt (?X,  ?K,  ?R) ) ) 


key=shared : 

sees ( ?P,  encrypt (?X,  ?K,  ?R) ) 
believes ( ?P,  shared_key ( ?K,  ?P,  ?Q) ) 
believes ( ?P,  says(?Q,  ?X) ) 


believes (?P,  says(?Q,  shared_key ( ?K,  ?P,  ?Q) ) ) 


content s^shared : 

believes ( ?P,  says ( ?Q,  encrypt ( ?X,  ?K,  ?R) ) ) 
believes (?P,  shared_key ( ?K,  ?P,  ?Q) ) 

believes (?P,  says (?Q,  ?X) ) 
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auth_mac : 

believes (?P,  shared_key (?K,  ?Q,  ?P) ) 
sees (?P,  mac ( ?K,  ?X) ) 
sees ( ?P,  ?X) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?K) ) 
believes (?P,  said(?Q,  mac(?K,  ?X) ) ) 

key_mac : 

sees(?P,  mac(?K,  ?X) ) 
believes(?P,  shared_key (?K,  ?P,  ?Q) ) 
believes (?P,  says(?Q,  ?X) ) 


believes(?P,  says(?Q,  shared^key (?K,  ?P,  ?Q) ) ) 
contents_mac : 

believes (?P,  says(?Q,  mac(?K,  ?X) ) ) 
believes(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  says(?Q,  ?X) ) 

seeing_secret : 

sees(?P,  combine (?X,  ?Y) ) 


sees ( ?P,  ?X) 
auth_secret : 

believes (?P,  secret (?Y,  ?Q,  ?P) ) 
sees(?P,  combine (?X,  ?Y) ) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?Y) ) 
believes (?P,  said(?Q,  combine (?X,  ?Y) ) ) 

key_secret : 

sees(?P,  combine(?X,  ?Y) ) 
believes (?P,  secret (?Y,  ?P,  ?Q) ) 
believes (?P,  says(?Q,  ?X) ) 


believes (?P,  says(?Q,  secret (?Y,  ?P,  ?Q) ) ) 
contents_secret  s 

believes (?P,  says(?Q,  combine (?X,  ?Y) ) ) 
believes (?P,  secret (?Y,  ?P,  ?Q) ) 
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believes (?P,  says(?Q,  ?X) ) 
seeing_public : 

sees(?P,  public_key ( ?K,  ?P) ) 
sees ( ?P,  encrypt (?X,  ?K,  ?R) ) 


sees (?P,  ?X) 
seeing_sig; 

sees(?P,  public_key (?K1,  ?Q) ) 
sees(?P,  encrypt (?X,  ?K2,  ?B) ) 
inv ( ?Kl ,  ?K2 ) 

sees ( ?P,  ?X) 

auth_sig: 

sees (?P,  encrypt ( ?X,  ?K2,  ?R)  ) 
believes (?P,  public_key ( ?K1 ,  ?Q) ) 
believes(?P,  recognizable (?X) ) 
inv ( ?K1 ,  ?K2 ) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?K2)) 

believes (?P,  said(?Q,  encrypt (?X,  ?K2,  ?R) ) ) 


key_sig: 

sees(?P,  encrypt (?x,  ?K2,  ?R) ) 
believes (?P,  public_key ( ?K1 ,  ?Q) ) 
believes (?P,  says(?Q,  ?X) ) 
inv ( ?K1 ,  ?K2 ) 

believes(?P,  says(?Q,  public^key (?K1,  ?Q) ) ) 
contents_sig: 

believes (?P,  says(?Q,  encrypt (?X,  ?K2,  ?R) ) ) 
believes (?P,  public_key (?K1,  ?Q) ) 
inv ( ?K1 ,  ?K2 ) 


believes (?P,  says(?Q,  ?X) ) 
contents„hash : 

believes (?P,  said(?Q,  hash(?X))) 
sees ( ?P,  ?X) 
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believes (?P,  said(?Q,  ?X) ) 
G- RULES 

f  reshness__list : 

believes (?P,  fresh (?X) ) 


believes (?P,  fresh (comma ( ?X,  ?Y) ) ) 

recognizing_list : 

believes ( ?P,  recognizable ( ?X) ) 


believes ( ?P,  recognizable (comma ( ?X,  ?Y) ) ) 

f reshness_shared_l : 

believes ( ?P,  fresh ( ?X) ) 
sees(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  fresh (encrypt ( ?X,  ?K,  ?R) ) ) 
freshness^shared_2 : 

believes (?P,  fresh (shared_key ( ?K,  ?P,  ?Q) ) ) 
sees(?P,  shared_key (?K,  ?P,  ?Q) ) 


believes (?P,  fresh (encrypt ( ?X,  ?K,  ?R) ) ) 

recognizing_shared; 

believes (?P,  recognizable ( ?X) ) 
sees(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  recognizable (encrypt ( ?X,  ?K,  ?R) ) ) 

f reshness_mac_l : 

believes ( ?P,  fresh ( ?X) ) 
sees(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  fresh (mac ( ?K,  ?X) ) ) 
f  reshness_mac_2 : 

believes(?P,  fresh (shared_key ( ?K,  ?P,  ?Q)  )  ) 
sees(?P,  shared^key ( ?K,  ?P,  ?Q) ) 


believes (?P,  fresh (mac ( ?K,  ?X) ) ) 

recognizing„mac ; 

believes (?P,  recognizable ( ?X) ) 
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sees ( ?P,  ghared_key ( ?K,  ?P,  ?Q) ) 


believes ( ?P,  recognizable (mac ( ?K,  ?X) ) ) 

f  reshness__secret_l : 

believes (?P,  fresh (?X) ) 

believes ( ?P,  fresh (combine (?X,  ?Y) ) ) 

freshness_secret_2  ; 

believes (?P,  fresh (secret ( ?Y,  ?P,  ?Q) ) ) 


believes (?P,  fresh (combine ( ?X,  ?Y) ) ) 

recognizing^secret  t 

believes ( ?P,  recognizable ( ?X) ) 


believes ( ?P,  recognizable (combine ( ?X,  ?Y) ) ) 

f  reshness__public_l : 

believes (?P,  fresh(?X)) 
sees(?P,  publicjcey ( ?K,  ?Q) ) 


believes (?P,  fresh (encrypt (?X,  ?K,  ?R) ) ) 
freshness_public_2 ; 

believes (?P,  fresh (public_key ( ?K,  ?Q) ) ) 
sees ( ?P,  public_key ( ?K,  ?Q)  ) 


believes (?P,  fresh (encrypt ( ?X,  ?K,  ?R) ) ) 

r  ecogni  z  ingjpubli  c : 

believes ( ?P,  recognizable ( ?X) ) 
believes(?P,  public_key ( ?K,  ?P) ) 


believes (?P,  recognizable (encrypt (?X,  ?K,  ?R) ) ) 

freshness_sig_l : 

believes ( ?P,  fresh ( ?X) ) 
sees(?P,  publicjtey  ( ?K1,  ?Q) ) 
inv ( ?Kl ,  ?K2 ) 

believes ( ?P,  fresh ( encrypt ( ?X ,  ?K2,  ?R) ) ) 


f  r e  shne  s  s_s i g_2 ; 
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believes ( ?P,  fresh (public_key ( ?K1 ,  ?Q) ) ) 
sees(?P,  public_key ( ?K1 ,  ?Q) ) 
inv(?Kl,  ?K2) 


believes (?P,  fresh (encrypt ( ?X,  ?K2,  ?R) ) ) 

recognizing__sig : 

believes ( ?P,  recognizable ( ?X) ) 
sees(?P,  public_key (?K1,  ?Q) ) 
inv ( ?K1 ,  ?K2) 


believes (?P,  recognizable (encrypt ( ?X,  ?K2,  ?R) ) ) 

f reshness_hash : 

believes (?P,  fresh (?X) ) 


believes (?P,  fresh (hash ( ?X) ) ) 


recogni z ing_hash : 

believes ( ?P,  recognizable ( ?X) ) 


believes ( ?P,  recognizable (hash ( ?X) ) ) 


END; 

//  - 

PROTOCOL  Challenged;  //  Logic;  AUTLOG 

VARIABLES 

A,  B:  Principal; 

Kab;  SKey; 

Rb:  Field; 

ASSUMPTIONS 

believes (B,  fresh (Rb) ) ; 
believes (B,  secret (Rb,  A,  B) ) ; 

MESSAGES 

1.  ?  ->  A;  encrypt (secret (Rb,  A,  B) ,  Kab,  B) ; 

2.  ?  ->  B:  combine(Rb,  Rb) ; 

GOALS 

believes (B,  says (A,  Rb) ) ; 

believes (A,  said(B,  secret (Rb,  A,  B) ) ) ; 


END; 
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Final  theory  representation  (size  10) : 
believes (B,  fresh (Rb) ) 
believes (B,  said (A,  Rb) ) 
believes(B,  said(A,  combine(Rb,  Rb) ) ) 
believes (B,  says (A,  Rb) ) 
believes (B,  says (A,  combine (Rb,  Rb) ) ) 
believes  (B,  says  (A,  secret  (Rb,  A,  33)  )  ) 
believes (B,  secret (Rb,  A,  B) ) 
sees (A,  encrypt (secret (Rb,  A,  B) ,  Kab,  B) ) 
sees(B,  Rb) 

sees (B,  combine (Rb,  Rb) ) 
critical  properties  for  this  theory: 
believes (B,  said (A,  Rb) ) 
believes (B,  says (A,  Rb) ) 
believes (B,  says (A,  combine (Rb,  Rb) ) ) 
believes (B,  says (A,  secret (Rb,  A,  B) ) ) 

desired  property;  believes (B,  says (A,  Rb) ) 
is  TRUE 

desired  property;  believes (A,  said(B,  secret(Rb,  A,  B) ) ) 
is  FALSE 


PROTOCOL  Challenge^;  //  Logic:  AUTLOG 

VARIABLES 

A,  B:  Principal; 

Kab:  SKey ; 

Rb:  Field; 


ASSUMPTIONS 

believes (B,  fresh (Rb) ) ; 
believes (B,  recognizable (Rb) ) ; 
believes (B,  shared_key (Kab,  A,  B) ) ; 
sees (B,  shared_key (Kab,  A,  B) ) ; 


MESSAGES 

1.  ?  ->  A:  Rb; 

2.  ?  ->  B:  encrypt (Rb,  Kab,  A); 
GOALS 


believes (B,  says (A,  Rb) ) ; 


END; 
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Final  theory  representation  (size  13) ; 
believes (B,  fresh (Rb) ) 
believes (B,  recognizable (Rb) ) 
believes (B,  said (A,  Kab) ) 
believes (B,  said (A,  Rb) ) 

believes (B,  said(A,  encrypt (Rb,  Kab,  A))) 
believes (B,  says (A,  Rb) ) 

believes (B,  says (A,  encrypt (Rb,  Kab,  A))) 
believes (B,  says (A,  shared_key (Kab,  A,  B) ) ) 
believes(B,  shared_key (Kab,  A,  B) ) 
sees (A,  Rb) 
sees(B,  Rb) 

sees(B,  encrypt (Rb,  Kab,  A)) 
sees(B,  shared_key (Kab,  A,  B) ) 
critical  properties  for  this  theory: 
believes (B,  said (A,  Kab)) 
believes (B,  said(A,  Rb) ) 
believes (B,  says (A,  Rb) ) 

believes (B,  says (A,  encrypt (Rb,  Kab,  A))) 
believes(B,  says (A,  shared_key (Kab,  A,  B) ) ) 

desired  property:  believes(B,  says(A,  Rb) ) 
is  TRUE 

// - 

PROTOCOL  Kerberos_Autlog;  //  Logic:  AUTLOG 

VARIABLES 

A,  B,  S:  Principal; 

Kab,  Kas,  Kbs :  SKey; 

Ta,  Ts:  Field; 

ASSUMPTIONS 

believes(A,  shared_key (Kas ,  S,  A)); 

believes(B,  shared_key (Kbs ,  S,  B) ) ; 

believes(S,  shared_key (Kas ,  A,  S) ) ; 

believes(S,  shared__key  (Kbs,  B,  S) ) ; 

believes(S,  shared__key  (Kab,  A,  B) ) ; 

believes (A,  controls (S,  shared_key ( ?K,  A,  B) ) ) ; 

believes (B,  controls (S,  sharedjcey ( ?K,  A,  B) ) ) ; 

believes (A,  fresh (Ts)); 

believes (B,  fresh (Ts) ) ; 

believes (A,  fresh (Ta) ) ; 

believes (B,  fresh (Ta) ) ; 

believes (A,  recognizable (shared_key (Kab,  A,  B) ) ) ; 
believes(B,  recognizable (shared_key (Kab,  A,  B) ) ) ; 
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sees (A,  sharedjcey (Kas,  S,  A)); 

sees(B,  shared_key (Kbs,  S,  B) ) ; 

sees(S,  shared_key (Kas,  A,  S) ) ; 

sees(S,  sharedjcey (Kbs ,  B,  S) ) ; 

sees(S,  shar ed_key ( Kab ,  A,  B) ) ; 

MESSAGES 

1.  ?  ->  A:  encrypt ( [Ts,  shared_key (Kab,  A,  B)  ,  encrypt ( [Ts, 

sharedjcey (Kab,  A,  B) ] ,  Kbs,  S) j ,  Kas,  S) ; 

2.  ?  ->  B;  [encrypt ( [Ts,  sharedjcey (Kab,  A,  B) ] ,  Kbs,  S) , 

encrypt ([Ta,  sharedjcey (Kab,  A,  B) ] ,  Kab,  A) ] ; 

3.  ?  ->  A:  encrypt ([Ta,  sharedjcey (Kab,  A,  B)  ]  ,  Kab,  B) j 

GOALS 

believes (A,  shar edjcey (Kab,  A,  B)  )  ; 
believes (B,  shared_key (Kab,  A,  B) ) ; 
believes (B,  says (A,  shared_key (Kab,  A,  B) ) ) ; 
believes (A,  says (B,  shared_key (Kab,  A,  B) ) ) ; 

END; 

Final  theory  representation  (size  79) :  [omitted] 

critical  properties  for  this  theory: 
believes (A,  said (B,  Kab) ) 
believes (A,  said(B,  Ta) ) 
believes (A,  said(S,  Kas) ) 
believes (A,  said(S,  Ts)) 
believes (A,  says(B,  Ta) ) 

believes (A,  says(B,  encrypt ([Ta,  shar ed_key (Kab,  A,  B) ] , 
Kab,  B))) 

believes(A,  says ( B ,  sharedjcey ( Kab ,  A,  B) ) ) 
believes (A,  says(S,  Ts)) 

believes (A,  says(S,  encrypt([Ts,  encrypt ([Ts, 

shared_key (Kab,  A,  B) ] ,  Kbs,  S) ,  sharedjcey ( Kab ,  A, 

B) ] ,  Kas,  S))) 

believes (A,  says (S,  encrypt ( [Ts,  sharedjcey (Kab,  A,  B) ] , 

Kbs ,  S) ) ) 

believes (A,  says ( S ,  sharedjcey (Kab,  A,  B) ) ) 
believes (A,  says(S,  sharedjcey ( Kas ,  A,  S) ) ) 
believes (A,  sharedjcey (Kab,  A,  B) ) 
believes (A,  sharedjcey ( Kas ,  A,  S) ) 
believes (B,  said (A,  Kab) ) 
believes (B,  said (A,  Ta) ) 
believes (B,  said (S,  Kbs) ) 
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believes(B,  said(S,  Ts)  ) 
believes (B,  says (A,  Ta) ) 

believes (B,  says (A,  encrypt ([Ta,  shared_key (Kab,  A,  B) ] , 
Kab,  A))) 

believes(B,  says(A,  shared„key ( Kab ,  A,  B) ) ) 
believes (B,  says(S,  Ts) ) 

believes (B,  says(S,  encrypt ([Ts,  shared_key (Kab,  A,  B) ] , 
Kbs,  S) ) ) 

believes (B,  says(S,  shared_key (Kab,  A,  B) ) ) 
believes (B,  says(S,  shared_key (Kbs,  B,  S) ) ) 
believes (B,  shared_key (Kab,  A,  B) ) 
believes(B,  shared_key (Kbs,  B,  S) ) 

desired  property;  believes  (A,  shared__key  (Kab,  A,  B)  ) 
is  TRUE 

desired  property:  believes (B,  shared_key (Kab,  A,  B)  ) 
is  TRUE 

desired  property:  believes(B,  says (A,  shared_key (Kab,  A,  B)  )  ) 
is  TRUE 

desired  property:  believes(A,  says(B,  shared_key (Kab,  A,  B)  )  ) 
is  TRUE 


B.3  Accountability 

Kailar’s  accountability  logic,  with  sample  protocol  specifications  and  Revere 
analyses: 

LOGIC  Accountability ; 

REWRITES 

comma_commutative : 

comma (?X,  ?Y)  =  comma (?Y,  ?X) 
comma_associative_l : 

comma (comma ( ?X,  ?Y) ,  ?Z)  =  comma (?X,  comma (?Y,  ?Z) ) 
comma^associativej ; 

comma(?X,  comma(?Y,  ?Z) )  =  comma ( comma ( ?X ,  ?Y) ,  ?Z) 

S -RULES 
inf : 

implies (?X,  ?Y) 
can_prove (?P,  ?X) 


can_prove ( ?P,  ?Y) 


B.3.  ACCOUNTABILITY 


conj  ; 


can_jprove  ( ?P, 

coirana  ( ?X, 

?Y)  ) 

can_prove ( ?Pf 

?X) 

sign: 

receives (?P, 
can_prove (??, 
inv ( ?K,  ?K' ) 

signed_with ( ?M,  ?K' ) ) 
authenticates ( ?K,  ?Q) ) 

can_prove (?P, 

says (?Q, 

?M)  ) 

extract^comma^l : 
can^prove (?P, 

says ( ?Q, 

comma (?X,  ?Y) ) ) 

can__prove  (?P, 

says ( ?Q, 

?X) ) 

extract_coirana_2 : 
receives ( ?P, 

comma (?X, 

?Y) ) 

receives ( ?P, 

?X) 

extracts  igned : 
receives ( ?P, 

signed_with(?X,  ?K) ) 

receives (?P, 

?X) 

trust ; 

can_prove ( ?P, 
can _prove ( ?P, 

says ( ?Q,  ?X) ) 
is_trusted_on ( ?Q,  ?X) ) 

canj)rove  ( ?P,  ?X) 


END; 


PROTOCOL  NetbillJ.;  //  Logic:  Accountability 
VARIABLES 

E,  P,  S ?  Principal; 

Kb',  Ke,  Ke\  K@f  Ks's  PKey; 

Service,  ServiceAck?  Field; 

ASSUMPTIONS 

can_j?rove  (S,  authenticates  (Ke,  E) )  ; 
canjrove  (E,  authenticates  (Ks,  S)  )  ; 
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can_prove(S,  authenticates (Kb,  B) ) ; 
can_prove(E,  authenticates (Kb,  B) ) ; 

implies (says (S,  Price ( ?Amt )) ,  AgreesTo(S,  Price (?Amt) )) ; 

implies (says (E,  Price (?Amt) ) ,  AgreesTo(E,  Price (?Amt) )) ; 

implies (says (S,  Service),  Rendersltem (S) ) ; 

implies (says (E,  ServiceAck) ,  Receivesltem (E) ) ; 

knows_key ( S ,  Ks ' )  ; 

knows_key (E,  Ke ' ) ; 

knows_key (B,  Kb ' ) ; 

inv(Ks,  Ks'); 

inv(Ke,  Ke'); 

inv(Kb,  Kb'); 

MESSAGES 

1.  ?  ->  E:  signed^with (Price (P) ,  Ks'); 

2.  ?  ->  S:  signed_with( [signed_with (Price (P) ,  Ks'), 

Price (P) ] ,  Ke' )  ; 

3.  ?  ->  E:  signed_with (Service,  Ks'); 

4.  ?  ->  S:  signed_with (ServiceAck,  Ke'); 

5.  ?  ->  S: 

[signed_with (encrypt ( [signed_with ( 

[signed^with (Price (P) ,  Ks'),  Price(P)],  Ke'), 
signed^with (ServiceAck,  Ke')],  Ks) ,  Kb'), 
signed_with ( encrypt ( [signed^with ( [signed_with (Price (P) , 
Ks'),  Price (P)],  Ke'),  signed_with (ServiceAck,  Ke')], 
Ke),  Kb')]; 

6.  ?  ->  E: 

s igned_with( encrypt ( [signed_with ( [signed_with (Price (P) , 
Ks'),  Price (P) ] ,  Ke'),  signed_with (ServiceAck,  Ke')], 
Ke),  Kb'); 

GOALS 

can_prove (E,  AgreesTo (S,  Price (P) ) ) ; 
can_prove (S,  AgreesTo (E,  Price (P) ) ) ; 
can_prove(E,  Rendersltem (S) ) ; 
can_prove(S,  Receivesltem (E) ) ; 

can_prove(E,  says(B,  [signed_with ( [signed_with (Price (P) , 
Ks'),  Price (P)],  Ke'),  signed_with (ServiceAck, 

Ke') ] ) ) ; 

can_prove(S,  says(B,  [signed_with ( [signed_with (Price (P) , 
Ks'),  Price (P)],  Ke'),  signed_with (ServiceAck, 

Ke')])); 


END; 
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Final  theory  representation  (size  44) ; 
ean_prove ( E ,  AgreesTo(S,  Price(P))) 
can_prove(E,  RendersItem(S) ) 

*  can_prove(E,  authenticates (Kb,  B) ) 
can„prove(E,  authenticates (Ks ,  S) ) 

can_prove ( E ,  says (B,  encrypt ( [signed_with (ServicoAck,  Ke' ) , 

*  signed_with( [Price (P) ,  signed_with (Price (P) ,  Ks')], 

Ke')] ,  Ke) ) ) 

can_prove (E,  says  (S,  Price (P) ) ) 
can_prove ( E ,  says ( S ,  Service)) 
can_prove(S,  AgreesTo(E,  Price(P))) 
can_prove(S,  ReceivesItem(E) ) 
canjrove(S,  authenticates  (Kb,  B)  ) 
can_prove ( S ,  authenticates (Ke,  E) ) 

can_prove ( S ,  says(B,  encrypt ( [signed_with (ServiceAck,  Ke'), 
signed_with( [Price (P) ,  signed_with (Price (P) ,  Ks')], 
Re')],  Ke))) 

car._prove  ( S ,  says  (B,  encrypt  (  [signed_with  (ServicoAck,  Ke'), 
signed_with ( [Price (P) ,  signed_with (Price (P) ,  Ks')], 
Ke')],  Ks))) 

can_prove(S,  says(E,  Price(P))) 
can_prove ( S ,  says (E,  ServiceAck) ) 

can_prove(S,  says(E,  [Price(P),  signed_with (Price (P) , 

Ks') ] )  ) 

can_provo ( S ,  says(E,  signed_with ( Price (P) ,  Ks'))) 

implies (says (E,  Price (?CAN0) ) ,  AgreesTo(E,  Price (7CAN0) ) ) 

injplies  (says  (E,  ServiceAck)  ,  ReceivesItem(E) ) 

implies (says (S,  Price ( ?CAN0 )) ,  AgreesTo(S,  Price ( ?CAN0) ) ) 

implies (says (S,  Service),  Renders I tern (S) ) 

inv (Kb,  Kb') 

inv(Ke,  Ke') 

inv ( Ks ,  Ks ' ) 

knows_,key ( B ,  Kb ' ) 

knows_key (E,  Ke ' ) 

knows_key (S,  Ks' ) 

receives (E,  Price (P) ) 

receives (E,  Service) 

receives (E,  encrypt ( [signed^with (ServiceAck,  Ke' ) , 

„  signed_with( [Price (P) ,  signed_with ( Price ( P) ,  Ks')], 

Ke')],  Ke)) 

receives (E,  signod_with (Price (P) ,  Ks')) 

.  receives (E,  signed_with ( Service ,  Ks')) 

receives  (E,  signed_with  ( encrypt  ( [sigr.ed_with  (ServiceAck, 
Ke'),  signed_with( [Price (P) ,  signed_with (Price (P) , 
Ks')] ,  Ke') ] ,  Ke) ,  Kb') ) 
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receives (S,  Price (P) ) 
receives (S,  ServiceAck) 

receives (S,  [Price (P),  signed_with (Price ( P) ,  Ks')]) 
receives (S,  [signed__with (encrypt ( [signed_with (ServiceAck, 
Ke' )  ,  signed__with  (  [Price  (P)  ,  signed_with  (Price  (P)  , 
Ks')],  Ke')],  Ke),  Kb'), 

signed__with  (encrypt  ( [signed_with (ServiceAck,  Ke')  , 
signed_with  (  [Price  (P)  ,  signed__with  (Price  (P)  ,  Ks ' )  ]  , 
Ke')],  Ks),  Kb')]) 

receives (S,  encrypt ( [signed_with ( ServiceAck,  Ke' )  , 

signed_with  (  [Price  (P)  ,  signed__with  (Price  (P)  ,  Ks ' )  ]  , 
Ke')],  Ke)) 

receives (S,  encrypt ( [signed_with (ServiceAck,  Ke ' )  , 

signed^with  (  [Price  (P)  ,  signed__with  (Price  (P)  ,  Ks ' )  ]  , 
Ke')] ,  Ks) ) 

receives (S,  signed_with (Price ( P) ,  Ks ' ) ) 
receives ( S ,  signed_wi th ( ServiceAck ,  Ke ' ) ) 
receives (S,  signed_with ( [Price (P) ,  signed_with (Price (P) , 
Ks')],  Ke')) 

receives (S,  signed_with (encrypt ( [signed_with (ServiceAck, 

Ke ' ) ,  signed_with ( [Price (P) ,  signed_with ( Price (P) , 
Ks')],  Ke')],  Ke),  Kb')) 

receives (S,  signed^with (encrypt ( [signed^with (ServiceAck, 

Ke' ) ,  signed_with ( [Price (P) ,  signed_with (Price (P) , 
Ks')],  Ke')],  Ks),  Kb')) 
critical  properties  for  this  theory; 

can__prove  (E,  AgreesTo(S,  Price  (P))) 
can_prove(E,  RendersItem(S) ) 

can_prove(E,  says(B,  encrypt  (  [signed__with  (ServiceAck,  Ke')  , 
signed__with  (  [Price  (P)  ,  signed__with  (Price  (P)  ,  Ks ' )  ]  , 
Ke')],  Ke))) 

can__prove  ( E ,  says(S,  Price  (P))) 
can_prove(E,  says(S,  Service)) 
can_prove(S,  AgreesTo(E,  Price (P) ) ) 
can_j?rove  (S,  ReceivesItem(E)  ) 

can_prove(S,  says(B,  encrypt ( [signed_with (ServiceAck,  Ke') , 
signed_with( [Price (P) ,  signed_with (Price (P) ,  Ks' ) ] , 
Ke')],  Ke))) 

can __prove  (S,  says  (B,  encrypt  (  [signed_with  (ServiceAck,  Ke' )  , 
signed_with ( [Price (P) ,  signed_with (Price (P) ,  Ks' ) ] , 
Ke')],  Ks))) 

can_prove (S,  says(E,  Price (P))) 

can_prove(S,  says(E,  ServiceAck)) 

canj»rove(S,  says(E,  signed_with  (Price  (P)  ,  Ks'))) 
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desired  property;  can_prove (E#  AgreesTo(S,  Price (P))) 
is  TRUE 


desired  property; 
is  TRUE 

desired  property: 


can_prove(S,  AgreesTo (E,  Price(P))) 
can_prove (E,  Render si t em (S) ) 


is  TRUE 

desired  property:  can_jprove  (S,  Receivesltem  (E)  ) 
is  TRUE 

desired  property;  can_prove (E,  says (B, 

[pigned_with ( [pigned_with ( Price (P) ,  Ks ' )  ,  Price (P) ] 
Ke' ) ,  signed_with (ServiceAck,  Ke' ) ] ) ) 


is  FALSE 

desired  property:  can_prove(S,  says(B, 

[signed^with ( [signed^with (Price (P) ,  Ks' )  ,  Price (P) ] 
Ke?) ,  signed^with (ServiceAck,  Ke' ) } ) ) 
is  FALSE 


// - 

PROTOCOL  Netbill_la;  //  Logic:  Accountability 

VARIABLES 

B,  E,  P,  S:  Principal; 

Kb,  Kb' ,  Ke,  Ke ' ,  Ks,  Ks's  PKey; 

Service,  ServiceAck:  Field; 

ASSUMPTIONS 

can_prove ( S ,  authenticates (Ke,  E) )  ; 
canj)rove (E,  authenticates (Ks,  S) ) ; 
can_prove (S,  authenticates (Kb,  B) ) ; 
can__prove  (E,  authenticates  (Kb,  B)  )  ; 

implies (says (S,  Price ( ?Amt) ) ,  AgreesTo (S,  Price ( ?Amt ) ) ) ; 

implies (says (E,  Price ( ?Amt ) ) ,  AgreesTo (E,  Price ( ?Amt ) ) ) ; 

implies (says (S,  Service) ,  RendersItem(S) ) ; 

implies (says (E,  ServiceAck) ,  ReceivesItem(E) ) ; 

knows_key (S,  Ks ' )  ; 

knows_key (E,  Ke ' )  ; 

knows_key  (B,  Kb ' )  ; 

inv (Ks,  Ks ' ) ; 

inv (Ke,  Ke'); 

inv (Kb,  Kb'); 

MESSAGES 

1 .  ?  ->  E;  signed_with (Price (P) ,  Ks ' )  ; 

2.  ?  ->  S;  signed_with( [signed_with (Price (P) ,  Ks ' )  , 

Price (P) ] ,  Ke ' )  ; 

3.  ?  ->  E:  signed^_with(  Service,  Ks ' )  ; 
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4.  ?  ->  S:  signed_with (ServiceAck,  Ke'); 

5.  ?  ->  B: 

encrypt (signed__with ( [signed_with ( [signed_with (Price (P)  , 
Ks ' )  ,  Price (P)  ]  ,  Ke').  signed_with (ServiceAck,  Ke')], 
Ks') ,  Kb) ; 

6.  ?  ->  S: 

[encrypt (signed_with ( [signed_with ( 

[signed_with (Price (P) ,  Ks'),  Price(P)],  Ke'), 
signed_with (ServiceAck,  Ke')],  Kb'),  Ks) , 
encrypt (signed_with( [signed_with ( [signed_with (Price (P)  , 
Ks'),  Price(P)],  Ke'),  signed_with (ServiceAck,  Ke')], 
Kb'),  Ke)]; 

7.  ?  ->  E: 

encrypt (signed_with ( [signed_with ( [signed_with (Price (P)  , 
Ks'),  Price(P)],  Ke'),  signed_with (ServiceAck,  Ke')], 
Kb') ,  Ke) ; 

GOALS 

can_prove (E,  AgreesTo (S,  Price (P) ) ) ; 
can__prove  ( S ,  AgreesTo  ( E ,  Price  ( P )  )  )  ; 
can_jprove  ( E ,  Renders  1 1  em  (S)  )  ; 
can_prove(S,  Receivesltem (E)  )  ; 

can^prove (E,  says (B,  [signed_with ( [signed^with (Price (P) , 
Ks'),  Price(P)],  Ke'),  signed_with (ServiceAck, 

Ke')])); 

can_prove(S,  says(B,  [signed_with ( [signed_with (Price (P) , 
Ks'),  Price(P)],  Ke'),  signed_with (ServiceAck, 

Ke')])); 


END; 

Final  theory  representation  (size  39) :  [omitted] 

critical  properties  for  this  theory: 

can_prove(E,  AgreesTo (S,  Price(P))) 

can_jprove  (E,  Rendersltem  (S)  ) 

can__prove  (E,  says(S,  Price  (P))) 

can_prove(E,  says(S,  Service)) 

can__prove(S,  AgreesTo  (E,  Price  (P))) 

can_prove(S,  ReceivesItem(E) ) 

can_prove (S,  says(E,  Price (P))) 

can_prove(S,  says(E,  ServiceAck)) 

can_prove(S,  says(E,  signed_with (Price (P) ,  Ks ' ) ) ) 

desired  property:  can_prove(E,  AgreesTo(S,  Price(P))) 
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is  TRUE 

desired  property:  can_prove(S,  AgreesTo(E,  Price(P))) 
is  TRUE 

desired  property:  can_j?rove  ( E ,  Renders  I  tern  (S)  ) 
is  TRUE 

desired  property:  can_prove (S,  Receivesltem (E) ) 
is  TRUE 


desired  property;  can  prove (E,  says (B, 

[signed_with( [signed„with (Price (P) ,  Ks' ) ,  Price (P) ] , 
Ke' )  ,  signed_with (ServiceAck,  Ke' ) ] ) ) 
is  FALSE 

desired  property:  can_prove(S,  says(B, 

[signed_with  (  [signed^with (Price (P)  ,  Ks ' )  ,  Price  (P)  ]  , 
Ke# ) ,  signed=with (ServiceAck,  Ke' ) ] ) ) 
is  FALSE 


// - - 

PROTOCOL  Netbill_2 ;  //  Logic;  Accountability 


VARIABLES 

B,  E,  P,  S:  Principal? 

Keb,  Kes:  SKey ; 

Kb,  Kb',  Ks,  Ks ' s  PKey; 

Service,  ServiceAck:  Field? 

ASSUMPTIONS 

can_prove (S,  authenticates (Ke,  E) ) ; 
can_prove (E,  authenticates (Ks ,  S) )  ; 
can_prove (S,  authenticates (Kb,  B) ) ; 
canj)rove (E,  authenticates (Kb,  B) ) ? 

implies (says (S,  Price (?Amt) ) ,  AgreesTo (S,  Price (?Amt) ) ) ; 

implies (says (E,  Price ( ?Amt ) ) ,  AgreesTo (E,  Price ( ?Amt) ) ) ; 

implies (says (S,  Service) ,  RendersItem(S) ) ; 

implies (says (E,  ServiceAck) ,  Receivesltem (E) ) ? 

knows_key (S,  Ks ' )  ; 

knows_key (E,  Ke ' ) ? 

knows^key (B,  Kb ' ) ; 

knows_key ( S ,  Kes ) ? 

knows^key (E,  Ke s ) ; 

knowsjcey ( B ,  Keb ) ; 

knowsjtey ( E ,  Keb ) ; 

inv (Keb,  Keb)? 

inv (Kes,  Kes) ; 

inv ( Ks ,  Ks'); 

inv(Ke,  Ke ' )  ? 

inv (Kb,  Kb'); 
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MESSAGES 
1.  ? 
2.  ? 

3.  ? 

4.  ? 

5.  ? 


->  E:  signed_with (Price (P) ,  Ks'); 

->  S:  [encrypt ( [signed_with (Price (P) ,  Ks'),  Price(P)], 
Keb) ,  encrypt (Price (P) ,  Kes) ] ; 

->  E:  signed_with (Service,  Ks'); 

->  S:  [encrypt (ServiceAck,  Kes),  encrypt (ServiceAck, 
Keb) ] ; 

->  B; 


signed_with ( encrypt ( [encrypt ( [signed_with (Price (P) , 
Ks'),  Price(P)],  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ,  Kb)  , 

Ks ' )  ; 


[signed_with (encrypt ( [encrypt ( [signed_with (Price (P)  , 
Ks'),  Price (P) ] ,  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb),  Ks')],  Keb), 
Kb')  , 

signed_with (encrypt ( [encrypt ( [signed_with (Price (P) , 
Ks'),  Price(P)],  Keb),  signed_with ( Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ,  Ks)  , 
Kb') ] ; 

7.  ?  ->  E: 

signed_with (encrypt ( [encrypt ( [signed_with (Price (P)  , 
Ks'),  Price(P)],  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb),  Ks')],  Keb), 
Kb')  ; 


GOALS 

can_prove ( E ,  AgreesTo (S,  Price (P) ) ) ; 
can_prove (S,  AgreesTo(E,  Price(P))); 
can^_prove  ( E ,  RendersItem(S) ) ; 
can_prove(S,  Receivesltem (E) ) ; 

can_prove (E,  says (B,  [encrypt ( [signed_with (Price (P) ,  Ks'), 
Price (P) ] ,  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with( encrypt (ServiceAck,  Keb),  Ks')])); 
can_prove(S,  says(B,  [encrypt ( [signed_with (Price (P) ,  Ks'), 
Price (P) ] ,  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb),  Ks')])); 


END; 

Final  theory  representation  (size  46) :  [omitted] 
critical  properties  for  this  theory; 
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can__prove  ( E ,  AgreesTo  ( S ,  Price  ( P )  )  ) 
can_prove(E,  Renders I tem(S) ) 

can_prove(E,  says(B,  encrypt ( [encrypt ( [Price (P) , 
signed_with (Price (P)  ,  Ks ' ) ] ,  Keb), 
signed__with (Price  (P)  ,  Ks  '  )  , 

signed_with( encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ,  Keb) ) ) 
can_prove(E,  says(S,  Price (P) ) ) 
can_prove ( E ,  says ( S ,  Service ) ) 

caruprove (£,  says (B,  encrypt ( [encrypt ( [Price (P) , 
signed_with (Price (P) ,  Ks')],  Keb), 
signed_with (Price (P) ,  Ks') , 

signed„with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ,  Keb) ) ) 
can_prove(S,  says (B,  encrypt ( [encrypt ( [Price (P) , 
signed^with (Price (P) ,  Ks')],  Keb), 
signed_with (Price (P) ,  Ks ' ) , 

signed_with( encrypt (ServiceAck,  Keb) ,  Ks' ) ] ,  Ks) ) ) 

desired  property:  can_jprove (E,  AgreesTo (S,  Price (P) ) ) 
is  TRUE 

desired  property:  can_prove(S,  AgreesTo(E,  Price(P))) 
is  FALSE 

desired  property:  canj)rove(E,  Renders It em (S) ) 
is  TRUE 

desired  property:  can^prove (S,  Receivesltem (E)  ) 
is  FALSE 

desired  property;  can  prove ( E ,  says (B, 

[encrypt ( [signed_with (Price (P) ,  Ks'),  Price(P) ] ,  Keb), 
signed„with( Price (P) ,  Ks' ) , 

signed__with  (encrypt  (ServiceAck,  Keb)  ,  Ks  ' )  ]  )  ) 
is  FALSE 

desired  property :  can_prove ( S ,  says ( B , 

[encrypt ( [signed^with (Price (P)  ,  Ks ' ) ,  Price (P) ] ,  Keb)  , 
signed_with( Price (P) ,  Ks' ) , 

signed_with (encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ) ) 
is  FALSE 

PROTOCOL  Netbill_2a;  //  Logic:  Accountability 
VARIABLES 

B,  E,  P,  S s  Principal? 

Keb :  SKey ; 

Kb,  Kb',  Ke',  Ks,  Ks';  PKey; 

Service,  ServiceAck:  Field; 


ASSUMPTIONS 
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can_prove(S,  authenticates (Ke,  E)  )  ; 
can_prove(E,  authenticates (Ks ,  S)  )  ; 
can_prove(S,  authenticates (Kb,  B) ) ; 
can_prove(E,  authenticates (Kb,  B) ) ; 

implies (says (S,  Price ( ?Amt) ) ,  AgreesTo(S,  Price (?Amt) )) ; 

implies (says (E,  Price (?Amt) ) ,  AgreesTo(E,  Price (?Amt) )) ; 

implies (says (S,  Service),  Renders I tern (S) ) ; 

implies (says (E,  ServiceAck) ,  Receivesltem (E) ) ; 

knows_key ( S ,  Ks ' ) ; 

knows_key (E,  Ke ' ) ; 

knows_key (B,  Kb ' )  ; 

knows_key ( S ,  Kes ) ; 

knows_key ( E ,  Kes ) ; 

knows_key (B,  Keb )  ; 

knows_key(E,  Keb); 

inv(Keb,  Keb) ; 

inv (Kes,  Kes); 

inv ( Ks ,  Ks ' )  ; 

inv ( Ke ,  Ke ' ) ; 

inv (Kb,  Kb'); 

MESSAGES 

1.  ?  ->  E:  signed^with ( Price ( P) ,  Ks'); 

2.  ?  ->  S:  [encrypt ( [signed_with ( Price (P) ,  Ks'),  Price (P) ] , 

Keb),  signed_with (Price (P) ,  Ke')]; 

3.  ?  ->  E;  signed_with( Service,  Ks'); 

4.  ?  ->  S:  [signed_with (ServiceAck,  Ke'), 

encrypt (ServiceAck,  Keb) ] ; 

5.  ?  ->  B: 

signed_with (encrypt ( [encrypt ( [signed_with (Price (P) , 
Ks'),  Price(P)],  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ,  Kb)  , 

Ks')  ; 

6.  ?  ->  S: 

[signed_with (encrypt ( [encrypt ( [signed_with (Price (P) , 
Ks'),  Price (P) ] ,  Keb),  signed_with ( Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb),  Ks')],  Keb), 

Kb')  , 

signed_with ( encrypt ( [encrypt ( [signed_with (Price (P) , 
Ks'),  Price(P)],  Keb),  signed_with (Price (P) ,  Ks'), 
signed_with (encrypt (ServiceAck,  Keb),  Ks')],  Ks) , 
Kb')]; 

7.  ?  ->  E: 

signed_with (encrypt ( [encrypt ( [signed_with (Price (P)  , 
Ks'),  Price(P)],  Keb),  signed_with( Price (P) ,  Ks'), 
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signed_with (encrypt (ServiceAck,  Keb) #  Ks' ) ] ,  Keb) , 
Kb')  ; 

GOALS 

can^prove (E,  AgreesTo (S,  Price (P) ) ) ; 
can_prove ( S ,  AgreesTo (E,  Price (P) ) ) ; 
can_prove (E,  Rendersltem (S) ) ; 
can_prove (S,  ReeeivesItem(E) ) ; 

can^prove (E,  says (B,  [encrypt ( [signed_with (Price (P) ,  Ks ' ) , 
Price (P) ] ,  Keb),  signed_with (Price (P) ,  Ks' )  , 
signed_with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ) ) ; 
can^prove (S,  says (B,  [encrypt ( [signed_with ( Price (P) ,  Ks' )  , 
Price (P)],  Keb),  signed_with (Price (P) ,  Ks ' ) , 
signed^with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ) ) ; 


END; 

Final  theory  representation  (size  52) :  [omitted] 

critical  properties  for  this  theory: 

can_prove(E,  AgreesTo (S,  Price (P))) 
can _prove ( E ,  Renders Item(S) ) 

can^prove (E,  says (B,  encrypt ( [encrypt ( [Price (P) , 
signed_with (Price (P) ,  Ks')],  Keb), 
signed_with (Price (P) ,  Ks ' ) , 

signed_with (encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ,  Keb) ) ) 
eanj>rove  (E,  says  (S,  Price  (P)  )  ) 
can__prove(E,  says(S,  Service)) 
can_prove(S,  AgreesTo(E,  Price(P))) 
can_prove(S,  ReceivesItem(E) ) 

canj)rove (S,  says (B,  encrypt ( [encrypt ( [Price (P) , 
signed_with (Price (P) ,  Ks')],  Keb), 
signed_with ( Price (P) ,  Ks' ) , 

signed_with (encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ,  Keb) ) ) 
can_prove (S,  says (B,  encrypt ( [encrypt ( [Price (P) , 
signed_with (Price (P) ,  Ks')],  Keb), 
signed_with (Price (P) ,  Ks' ) , 

signed^with (encrypt (ServiceAck,  Keb) ,  Ks' ) ] ,  Ks) ) ) 
can_prove(S,  says(E,  Price (P) ) ) 
can__prove  (S,  says  (E,  ServiceAck)  ) 

desired  property:  can^prove ( E ,  AgreesTo (S,  Price (P) ) ) 
is  TRUE 

desired  property;  canj>rove  (S,  AgreesTo  (E,  Price  (P) )  ) 
is  TRUE 
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desired  property:  can_prove(E,  Rendersltem (S) ) 
is  TRUE 

desired  property:  can_prove(S,  Receivesltem (E) ) 
is  TRUE 

desired  property:  can_prove(E,  says(B, 

[encrypt ( [signed_with (Price (P)  ,  Ks ' ) ,  Price  (P) ] ,  Keb) , 
signed_with (Price (P) ,  Ks ' ) , 

signed.. with (encrypt  (ServiceAck,  Keb)  ,  Ks' )  ]  )  ) 
is  FALSE 

desired  property;  can_prove(S,  says(B, 

[encrypt ( [signed_with ( Price (P) ,  Ks ' ) ,  Price (P) ] ,  Keb) , 
signed__with  (Price  (P)  #  Ks ' )  , 

signed__with (encrypt (ServiceAck,  Keb) ,  Ks ' ) ] ) ) 
is  FALSE 

//  - 

PROTOCOL  SPX;  //  Logic:  Accountability 

VARIABLES 

C,  S :  Principal ; 

Kcdc ' ,  Kdel,  Ktal ' ,  Kta2 ' :  SKey; 

Kc#  Kc ' ,  Ks:  PKey ; 

ASSUMPTIONS 

canj>rove(C,  authenticates  (Kcdc,  CDC)  )  ; 

can_prove(S,  authenticates (Kcdc,  CDC) ) ; 

can_prove(C,  authenticates (Ktal,  TA1 ) ) ; 

can_prove(S,  authenticates (Kta2 ,  TA2 ) ) ; 

can_prove(C,  is„trusted_on (CDC ,  ?X) ) ; 

can_prove(S,  is_trusted_on (CDC,  ?X)  ) ; 

can_prove(C,  is^trusted^on (TA1 ,  ?X) ) ; 

canj)rove (S,  is_trusted_on (TA2 ,  ?X) ) ; 

can_prove(S,  is_trusted_on (C,  authenticates ( ?K,  C) ) ) ; 

knows_key ( S ,  Ks ' ) ; 

knows^key ( C ,  Kc ' ) ; 

knows_key ( CDC ,  Kcdc ' ) ; 

inv(Ks,  Ks' ) ; 

inv(Kc,  Kc' ) j 

inv (Kdel ,  Kdel ' ) ; 

inv ( Kcdc ,  Kcdc ' ) ; 

inv (Ktal,  Ktal'); 

inv (Kta2 ,  Kta2 ' ) ; 

MESSAGES 

X.  ?  “>  C;  signed__with (signed_with( authenticates  (Ks,  S)  , 
Ktal'),  Kcdc'); 
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2.  ?  ->  S;  signed_with (authenticates (Kdel,  C)  ,  Kg'); 

3.  ?  ->  S:  signed__with (signed_with (authenticates  (Kc,  C)  , 

Kta2 7 ) ,  Kcdc ' ) ; 

GOALS 

can_prove(C,  authenticates (Ks,  S) ) ; 
can_prove (S,  authenticates (Kc,  C) ) ; 
can_prove (S,  authenticates (Kdel,  C) ) ; 

END; 

Final  theory  representation  (size  36):  [omitted] 

critical  properties  for  this  theory: 
can__prove  (C,  authenticates (Ks ,  S)  ) 
ean_prove(C,  is_trusted__on  (CDC,  7CAN0) ) 
can_prove (C,  is_trusted_on (TAl ,  7CAN0) ) 

ean_prove (C,  says (CPC,  signed_with (authenticates (Ks,  S)  , 
Ktal ' )  )  ) 

can_prove(C,  says(TAl,  authenticates (Ks ,  S) ) ) 
can_prove(C,  signed_with (authenticates (Ks ,  S) ,  Ktal')) 
canT?Tprove(S#  authenticates  (Kc,  C)  ) 
can^jorove  (S,  authenticates  (Kdel ,  C)  ) 

canj)rove (S,  is^trusted^on (C,  authenticates ( ?CAN0 ,  C) ) ) 
can_prove (S,  is_trusted_on (CDC ,  ?CAN0 ) ) 
can_prove (S,  is_trusted_on (TA2 ,  7CAN0 ) ) 
can_prove (S,  says (C,  authenticates (Kdel,  C) ) ) 
can_prove (S,  says (CDC,  signed_with (authenticates (Kc,  C)  , 
Kta2 ' ) ) ) 

can_prove(S,  says(TA2,  authenticates (Kc ,  C) ) ) 
canj)rove(S,  signed^with (authenticates (Kc ,  C)  ,  Kta2 ' ) ) 

desired  property:  can_prove (C,  authenticates (Ks ,  S) ) 
is  TRUE 

desired  property:  can_prove (S,  authenticates (Kc,  C) ) 
is  TRUE 

desired  property:  can__prove  (S,  authenticates (Kdel,  C) ) 
is  TRUE 


BA  RV 

RV  rules  and  rewrites,  with  sample  protocol  specifications  and  Revere  analyses: 


LOGIC  RV; 
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REWRITES 

comma_commutative : 

comma (?X,  ?Y)  =  comma (?Y,  ?X) 
comma_associative_l : 

comma (comma (?X,  ?Y) ,  ?Z)  =  comma(?X,  comma(?Y,  ?Z)) 
comma_associative_2 : 

comma ( ?X,  comma(?Y,  ?Z))  =  comma ( comma ( ?X ,  ?Y) ,  ?Z) 
seq_associative_l : 

seg(seq(?X,  ?Y)  ,  ?Z)  =  seq(?X,  seq(?Y,  ?Z)) 
seq_associative_2 : 

seg ( ?X,  seq(?Y,  ?Z))  =  seg(seg(?X,  ?Y) ,  ?Z) 
shared_key_commutative : 

shared_key ( ?K,  ?Q,  ?R)  =  shared_key (?K,  ?R,  ?Q) 
secret^commutative : 

secret ( ?Y,  ?Q,  ?R)  =  secret (?Y,  ?R,  ?Q) 


S-RULES 

seeing_list : 

sees(?P,  comma (?X,  ?Y) ) 


sees (?P, 

?X) 

seeing_seg: 

sees ( ?P, 

seg ( ?X,  ?Y) ) 

sees ( ?P, 

?X) 

sees (?P, 

?Y) 

seeing_tagged : 

sees ( ?P, 

tagged (?T,  ?Y) ) 

sees ( ?P#  ?Y) 


list_said: 

believes (?P, 


believes ( ?P, 


said(?Q,  comma (?X, 


said ( ?Q,  ?X) ) 


?Y)  )  ) 


list_says : 

believes (?Pf 


believes ( ?P, 


says ( ?Q ,  comma ( ?X , 


says ( ?Q,  ?X) ) 


?Y))) 


nonce_verification; 
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believes ( ?P,  fresh ( ?X) ) 
believes (?P,  said(?Q,  ?X) ) 


believes (?P,  says(?Q/  ?X) ) 
jurisdictions 

believes (?P,  controls (?Q,  ?X) ) 
believes (?P,  says (?Q,  ?X) ) 


believes ( ?P,  ?X) 
seeing_shared : 

sees(?P,  sharedjcey (?K,  ?Q,  ?R) ) 
sees(?P,  encrypt (?X,  ?K) ) 


sees(?P,  ?X) 


auth_shared : 

believes (?P,  shared_key ( ?K,  ?Q,  ?P) ) 
sees(?P,  encrypt (?X,  ?K) ) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?K) ) 
believes (?P,  said(?Q,  encrypt (?X,  ?K) ) ) 

key_shared ; 

sees (?P,  encrypt (?X,  ?K) ) 

believes ( ?P,  shared_key ( ?K,  ?P,  ?Q) ) 

believes (?P,  says(?Q,  ?X) ) 


believes (?P,  says (?Q,  shared_key ( ?K,  ?P,  ?Q) ) ) 


cont ent s_shared : 

believes ( ?P,  says(?Q,  encrypt ( ?X,  ?K) ) ) 
believes (?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  says(?Q,  ?X) ) 
auth_mac : 

believes (?P,  shared^key ( ?K,  ?Q,  ?P) ) 
sees (?P,  mac ( ?K,  ?X) ) 
sees ( ?P,  ?X) 

believes ( ?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?K) ) 
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believes (?P,  said(?Q,  mac(?K,  ?X) ) ) 
key__mac : 

sees ( ?P,  mac ( ?K,  ?X) ) 

believes (?P,  shared_key ( ?K,  ?P,  ?Q) ) 

believes (?P,  says(?Q,  ?X) ) 


believes (?P,  says(?Q,  shared_key ( ?K,  ?P,  ?Q) ) ) 
contents_mac; 

believes (?P,  says(?Q,  mac(?K,  ?X) ) ) 
believes(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  says(?Q,  ?X) ) 


seeing_secret : 

sees(?P,  combine (?X,  ?Y) ) 


sees ( ?P#  ?X) 
auth_secret : 

believes (?P,  secret (?Y,  ?Q,  ?P)  ) 
sees(?P,  combine (?X,  ?Y) ) 


believes (?P,  said(?Q,  ?X) ) 
believes (?P,  said(?Q,  ?Y) ) 
believes (?P,  said(?Q,  combine (?X,  ?Y) ) ) 

key_secret : 

sees(?P,  combine (?X,  ?Y) ) 
believes (?P,  secret (?Y,  ?P,  ?Q) ) 
believes (?P,  says(?Q,  ?X) ) 


believes (?P,  says(?Q,  secret (?Y,  ?P,  ?Q) ) ) 
contents_secret : 

believes (?P,  says(?Q,  combine (?X,  ?Y) ) ) 
believes (?P,  secret (?Y,  ?P,  ?Q) ) 


believes (?P,  says(?Q,  ?X) ) 
seeing_public : 

sees(?P,  publicjtey  ( ?K,  ?P) ) 
sees ( ?P,  encrypt (?X,  ?K) ) 
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sees (?P,  ?x) 
seeing_sig: 

sees(?P,  public_key (?K1,  ?Q) ) 
sees(?P,  encrypt (?X,  ?K2)) 
inv ( ?K1 ,  ?K2) 

sees ( ?P,  ?X) 

autb_sig; 

sees(?P,  encrypt (?X,  ?K2)) 
believes(?P,  public^key ( ?K1 ,  ?Q) ) 
inv ( ?K1 ,  ?K2 ) 


believes (?P,  said(?Q,  ?X) ) 

believes (?P,  said(?Q,  ?K2) ) 

believes ( ?P,  said ( ?Q,  encrypt ( ?X,  ?K2 ) ) ) 

key__sig ; 

sees(?P,  encrypt (?X,  ?K2)) 
believes (?P,  public_key ( ?K1 ,  ?Q) ) 
believes (?P,  says(?Q,  ?X) ) 
inv ( ?Kl ,  ?K2 ) 


believes ( ?P,  says(?Q,  public_key ( ?Kl ,  ?Q) ) ) 
eontents_sig: 

believes (?P,  says(?Q,  encrypt (?X,  ?K2))) 
believes(?P,  publicjcey { ?K1 ,  ?Q) ) 
inv ( ?K1 ,  ?K2) 

believes (?P,  says ( ?Q,  ?X) ) 
content s_hash : 

believes (?P,  said(?Q,  hash(?X))) 
sees ( ?P,  ?X) 


believes (?P,  said(?Q,  ?X) ) 

maysee^sharedjcey : 

sees (?P,  sharedjcey (?Q,  ?R) ) 

believes (?P,  maysee (?Q,  ?K) ) 


maysee_secret ; 
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sees ( ?P,  secret ( ?Y,  ?Q,  ?R) ) 


believes (?P,  maysee(?Q#  ?Y) ) 

maysee_privkey : 

sees(?P,  public_key (?K1,  ?Q) ) 
inv ( ?K1 ,  ?K2 ) 


believes (?P,  maysee(?Q,  ?K2)) 

may  s  e  e_s  e  e  i  ng_i  s__be  1  i  e  vi  ng : 
sees(?P,  maysee(?Q,  ?X) ) 


believes (?P,  maysee(?Q,  ?X) ) 

maysee_sees_maysee : 

sees(?P,  sees(?Q,  ?X) ) 


believes (?P,  maysee(?Q,  ?X) ) 
maysee_comma : 

believes (?P,  maysee(?Q,  comma (?X,  ?Y) ) ) 


believes (?P,  maysee(?Q,  ?X) ) 

maysee_pubkey ; 

sees(?P,  public_key (?K,  ?Q) ) 


believes (?P,  maysee(?I,  ?K) ) 
G-RULES 

freshness^list : 

believes (?P,  fresh (?X) ) 


believes (?P,  fresh (comma ( ?X,  ?Y) ) ) 

f reshness_seq_l ; 

believes (?P,  fresh (?X) ) 


believes (?P,  fresh (seq ( ?X,  ?Y) ) ) 

f reshness_seq_2 : 

believes ( ?P,  fresh ( ?X) ) 


believes (?P,  fresh(seq(?Y,  ?X) ) ) 
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f reshness_tagged : 

believes ( ?P,  fresh ( ?X) ) 


believes ( ?P,  fresh (tagged ( ?T,  ?X) ) ) 

f reshness_shared_l : 

believes ( ?P,  fresh ( ?X) ) 

sees (?P,  shared_key (?K,  ?P,  ?Q) ) 


believes ( ?P,  fresh (encrypt ( ?X,  ?K) ) ) 
freshness_shared_2 : 

believes (?P,  fresh (sharedjcey ( ?K,  ?P,  ?Q)  )  ) 
sees(?P,  shared^key ( ?K,  ?P,  ?Q)  ) 

believes ( ?P,  fresh (encrypt ( ?X,  ?K) ) ) 

f  re  shne  s  s_jnac_l ; 

believes (?P,  fresh (?X) ) 
sees(?P,  shared_key ( ?K,  ?P,  ?Q) ) 


believes (?P,  fresh (mac ( ?K,  ?X) ) ) 
freshness_mac_2 : 

believes  (?P,  fresh  ( shared_key  ( ?K,  ?P,  ?Q)  )  ) 
sees (?P,  shared_key (?K,  ?P,  ?Q) ) 


believes (?P,  fresh (mac ( ?K,  ?X) ) ) 

f reshness_secret=l : 

believes ( ?P,  fresh ( ?X) ) 


believes ( ?P,  fresh (combine ( ?X,  ?Y) ) ) 
freshness_secret_2 : 

believes (?P,  fresh (secret ( ?Y,  ?P,  ?Q) ) ) 
believes ( ?P,  fresh (combine (?X,  ?Y) ) ) 


f  re  shne  s  s_pub  1  i  c^_l  ? 

believes (?P,  fresh (?X) ) 
sees ( ?P,  public_key ( ?K,  ?Q) ) 


believes (?P,  fresh (encrypt ( ?x,  ?K) ) ) 
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freshness_public__2 : 

believes ( ?P,  fresh (public_key ( ?K,  ?Q) ) ) 
sees(?P,  public_key ( ?K,  ?Q) ) 


believes (?P,  fresh (encrypt (?X,  ?K) ) ) 

freshness_sig_l : 

believes (?P,  fresh (?X) ) 
sees(?P,  public_key (?Kl,  ?Q) ) 
inv ( ?K1 ,  ?K2) 


believes ( ?P,  fresh (encrypt ( ?X,  ?K2 ) ) ) 
freshnessr_sig_2 ! 

believes (?P,  fresh (public_key ( ?K1 ,  ?Q) ) ) 
sees(?P,  public_key ( ?K1 ,  ?Q) ) 
inv ( ?K1 ,  ?K2) 


believes (?P,  fresh (encrypt (?X,  ?K2) ) ) 

f  r eshnes  s Jhash : 

believes ( ?P,  fresh ( ?X) ) 


believes ( ?P,  fresh (hash ( ?X) ) ) 

introspection_seeing ; 
sees ( ?P,  ?X) 


believes (?P,  sees(?P,  ?X) ) 

maysee_encrypt_shared : 

believes (?P,  maysee(?Q,  ?X) ) 
believes (?P,  maysee(?R,  ?X) ) 
believes(?P#  shared_key ( ?K#  ?Q,  ?R) ) 


believes (?P,  jnaysee(?p,  encrypt  (?X,  ?K)  )  ) 

maysee_encrypt_public : 

believes (?P,  maysee(?Q,  ?X) ) 
believes(?P,  publicjtey ( ?K,  ?Q) ) 


believes (?P,  maysee(?I,  encrypt (?X,  ?K) ) ) 


maysee__encrypt ; 
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believes ( ?P,  maysee ( ?Q, :  ?X) ) 


believes(?P,  maysee(?Q,  encrypt  ( ?X,  ?.K)  )  ) 
maysee^concat : 

believes (?P,  maysee (?Q,  ?X) ) 
believes (?P,  maysee (?Q,  ?Y) ) 


believes (?P,  maysee (?Q,  seq(?X,  ?Y) ) ) 

has_sees: 

sees (?P,  ?X) 


has ( ?P,  ?X) 

has^seq: 

has (?P,  ?X) 
has (?P,  ?Y) 


has ( ?P,  seq ( ?X,  ?Y) ) 

has_tagged: 
has ( ?P,  ?X) 


has ( ?P,  tagged (?Y,  ?X) ) 

has_encrypt : 
has ( ?P,  ?X) 
has ( ?P,  ?K) 


has ( ?P,  encrypt (?X,  ?K) ) 
has  jpubkey : 

believes(?P,  public_key (?K,  ?Q) ) 


has(?P,  ?K) 
has_privkey : 

believes(?P,  public_key ( ?K1 ,  ?P) ) 
inv ( ?K1 ,  ?K2 ) 

has ( ?P,  ?K2 ) 

legit_seq: 

believes (?Q,  legit (?X) ) 
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believes ( ?Q,  legit ( ?Y) ) 


believes (?Q,  legit (seq ( ?X,  ?Y) ) ) 

legit_encrypt : 

believes ( ?Q,  legit ( ?X) ) 
believes (?Q,  public_key ( ?K,  ?P) ) 


believes ( ?Q,  legit (encrypt ( ?X,  ?K) ) ) 


END; 

// - - - - - 

PROTOCOL  Needham_Schroeder_Pub_l ;  //  Logic:  RV 

VARIABLES 

A,  B,  S:  Principal; 

Ka,  Kb,  Ks,  Ks';  PKey; 

Na,  Nb,  msg6_tag,  msg7_tag:  Field; 


ASSUMPTIONS 
believes (A, 
believes (A, 
believes (B, 
believes (B, 
believes (S, 
believes (S, 
believes (S, 


public_key (Ka, 
publicjcey (Ks, 
public_key (Kb, 
public_key (Ks, 
public__key  (Ka, 
public_key (Kb, 
public_key (Ks, 


A) ) 
S)) 

B)  ) 
S)) 

A) ) 

B)  ) 
S)  ) 


sees(A,  publicjcey  (Ka,  A) ) ; 
sees(A,  public_key (Ks,  S) ) ; 
sees (B,  public_key (Kb,  B) ) ; 
sees(B,  public_key (Ks,  S) ) ; 
sees(S,  public_key (Ka,  A)); 
sees(S,  public_key (Kb,  B) ) ; 
sees(S,  public_key (Ks,  S) ) ; 

believes (A,  controls (S,  public_key ( ?K,  B) ) ) ; 
believes (B,  controls (S,  publicjcey ( ?K,  A))); 

believes (A,  fresh (Na) ) ; 
believes (B,  fresh (Nb) ) ; 

believes (A,  secret (Na,  A,  B)  )  ; 
believes (B,  secret (Nb,  A,  B) ) ; 


BA.  RV 
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//  As  in  the  BAN  analysis,  these  two  assumptions  represent  the 
//  protocol  weakness  that  each  principal  must  assume  that  the 
//  message  containing  the  public  key  of  the  other  principal  is 
//  fresh. 

believes (A,  fresh (public_Jcey (Kb,  B) ) ) ; 
believes (B,  fresh (public_key (Ka,  A)  )  )  ; 

inv ( Ks ,  Ks ' ) ; 


has (P,  P)  ; 
has (A,  B) ; 
has (A,  Na)  ; 
has (B,  Nb) ; 


//  ===  Interpretations  ===== 

//  messages  2  &  5  (public  key  certs  from  the  server) 
interp (  //  conclusion 

believes (?Q,  says(?P,  publicjtey  (?K,  ?R) ) ) , 

//  premises 

believes (?Q,  says(?P,  tagged (conc_tag,  seq(?K,  ?R) ) ) ) 

)  ; 


//  message  3  needs  no  interpretation 


//  two-step  interpretation  of  message  6 


// 

// 

// 

// 

// 

// 

// 

// 

// 


NOTE:  w/o  msg6_tag,  this  interpretation  could  also 
be  applied  to  message  3;  that  represents  an 
(arguable)  weakness  in  the  protocol.  If  A 
initiates  the  protocol  with  A,  then  an  intruder 
can  pose  as  (the  other)  A  by  replaying  message 
3  as  message  6.  Then  A  believes  that  "A"  is  a 
nonce  that  (the  other)  A  believes  to  be  secret, 
when  in  fact  the  other  A  (rightfully)  does  not 
believe  this.  Not  a  very  practical  attack, 


interp (  //  conclusion 

sees ( ?Q,  combine (tagged (msg6_tag,  ?N2 ) ,  ?N1 ) ) , 
//  premises 

sees ( ?Q,  seq(?Nl,  ?N2)) 

)? 


interp (  //  conclusion 
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believes (?Q,  says(?P#  secret (?N2,  ?P,  ?Q) ) ) , 
//  premises 

believes (?Q,  says(?P,  tagged (msg6_tag,  ?N2 ) ) ) 

)  ; 


//  two-step  interpretation  of  message  7 
interp(  //  conclusion 

sees ( ?Q,  combine (tagged (msg7_tag,  ?N1),  ?N1)), 
//  premises 
sees(?Q,  ?Nl ) 

)  ; 


//  Note:  conclusion  includes  a  protocol-instance 
//  variable  (Na) 

interp(  //  conclusion 

believes ( ?Q,  says ( ?P, 
comma (secret (Na,  ?P,  ?Q) , 

says ( ?Q,  secret (?N2,  ?p,  ?Q) ) ) ) ) , 

//  premises 

believes (?Q,  says(?P,  tagged (msg7_tag,  ?N2 ) ) ) 
) ; 


MESSAGES 

// 

concrete  messages 

1. 

A  ->  S:  seq(A,  B) ; 

2, 

S  ->  A;  encrypt (seq (Kb, 

B)  , 

Ks '  )  ; 

3. 

A  ->  B:  encrypt (seq (Na, 

A)  , 

Kb)  ; 

4. 

B  ->  S:  seq(B,  A) ; 

5. 

S  ->  B:  encrypt (seq (Ka, 

A)  , 

Ks '  )  ; 

6. 

B  ->  A:  encrypt (seq (Na, 

Nb) 

,  Ka); 

7. 

A  ->  B:  encrypt (Nb,  Kb) 

/ 

GOALS 

//  these  two  do  *not*  hold  unless  the  pk  certs  are 
//  initially  believed  fresh 
believes (A,  public_key (Kb,  B) ) ; 
believes(B,  public_key (Ka,  A) ) ; 

believes (A,  says(B,  secret (Nb,  A,  B) ) ) ; 
believes (B,  says (A,  secret (Na,  A,  B) ) ) ; 

believes (B,  says (A,  says(B,  secret (Nb,  A,  B) ) ) ) ; 


END; 


Final  theory  representation  (size  155) :  [omitted] 


desired  property: 
is  TRUE 

desired  property: 
is  TRUE 

desired  property; 
is  TRUE 

desired  property; 
is  TRUE 

desired  property: 
is  TRUE 


believes(A,  public_key (Kb,  B) ) 
believes (B,  publicjkey (Ka,  A)) 
believes (A,  says (B,  secret (Nb,  A,  B)  )  ) 
believes (B#  says (A,  secret (Na,  A,  B) ) ) 
believes (B,  says (A,  says(B,  secret (Nb,  A,  B) ) ) ) 


Interpretation  rules:  INVALID  [13  violated  by  rule  5] 
Honesty  check:  PASS 
Secrecy  check;  PASS 
Feasibility  check:  PASS 
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